-
Notifications
You must be signed in to change notification settings - Fork 877
Array code bloat reduction #4961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a981348 to
399861e
Compare
efc60e1 to
b35bc2a
Compare
vonzshik
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, though I'm not sure whether the casts are necessary.
roji
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks, and not as complicated as I feared it might be 😅
Some thoughts:
- We can make arrays as a whole opt-in via NpgsqlSlimDataSourceBuilder (#4965). At that point reducing the array overhead becomes less important, but this significant size reduction for those who do opt in is still definitely nice to have.
- On the other hand, this adds some overhead for arrays (concurrent dictionary lookup per array operation, more virtual calls per array element). It could be claimed that if you opt into arrays, you'd rather have them faster and are willing to pay a bit of size for that; though I'm guessing the runtime overhead added here is probably negligible (maybe a benchmark would help).
- We've been discussing redoing/changing type handlers in general because the current design is problematic/convoluted (e.g. more in the direction of Slon). If we do that, then the churn here may not be worth it.
To be clear I'm totally fine with merging this (though a quick benchmark would be nice), just pointing out some points.
Through the eye of the needle