Why are you excited? I have no idea, because upon loading the site, literally all of my screen is filled with advertising, a disgusting AI slop image, and an admittedly well-intentioned 1/3 height popup about kindness.
There is literally no content visible. It’s just awful slop, advertising, and pop-ups as far as the eye can see.
Hell, you didn’t even have to use AI slop for the image of the elephant … I did a quick search and found loads of Creative Commons licensed photos of real elephants.
Here’s what ellama-summarize-webpage gives me (I’m running Emacs integrated with an LLM running locally on my desktop):
The author shares their experience of reducing query times significantly for a Ruby on Rails app
that utilizes PostgreSQL, thanks to a proposed patch by Peter Geoghegan that improves B-tree
indexing. The app’s response time improved from 110ms to just 10ms with the new patch and PostgreSQL
17 beta. The author encourages upgrading to PostgreSQL 17 for further improvements, as well as
delving deeper into database optimization. They also recommend sharing feedback and benchmarks on
the PostgreSQL hackers mailing list. Overall, the author highlights how the proposed patch can lead
to faster response times, particularly in challenging scenarios where query times are high.
Sorry if my original reply seemed harsh - my issue was with dev.to, not at all with you or your article :) I’ve re-submitted your blog post to lobste.rs on the new URL :)
tl;dr? multiple IN expressions in a query now use indexes; you don’t have to write (a=? OR a=? OR a=?) you can just write a IN (?,?,?)
I haven’t used postgres seriously in a decade or more, so I’m unlikely to go change the one app I made once upon a time that still uses postgres to take advantage of this optimisation, but I clicked the link hoping to learn something anyway…
That seems to be it, and seems to be little more than a syntactic convenience when compared like this, but it could be significant if the new optimisation covers dynamic cases as well, like an ANY expression with a data-dependent array. Though even if it doesn’t work on dynamic cases, you could still say that a pitfall got ironed out.
That said, even though this post only mentions this IN optimisation, Postgres 17 does indeed seem to come with quite a lot of other optimiser improvements, seems significantly more than usual.
It does also note a gain for single list predicates by avoiding an index query per value, and that can be significant if the list is large, but it’s not clear if scalars are affected or were optimised for this case and I don’t have a pg on hand to test.
I feel like the link should probably be replaced with this one, because it has actual content. The current one feels spammy and it barely has anything to do with Rails or Ruby.
(This was originally posted as a dev.to article, which wound up with the comments being 99% about how awful dev.to is, and 1% about the content itself. The author since reposted at their blog, so I thought it would make sense to submit the blog link instead).
Why are you excited? I have no idea, because upon loading the site, literally all of my screen is filled with advertising, a disgusting AI slop image, and an admittedly well-intentioned 1/3 height popup about kindness.
There is literally no content visible. It’s just awful slop, advertising, and pop-ups as far as the eye can see.
Hell, you didn’t even have to use AI slop for the image of the elephant … I did a quick search and found loads of Creative Commons licensed photos of real elephants.
https://postimg.cc/8sm6hvMV
I agree, it’s not ideal how modern websites are just piles of AI elephant dung. Anyway, why were they interested?
Because of this:
With a fix that made it into 17, an example query (ab)using multiple query parameters went from over 8 seconds to 0.11 seconds.
That’s literally it.
I mean, that’s exciting as anything if you happen to run a site that uses PostreSQL in that way :)
Can an AI summarizer summarize this as well as you have? I wonder: what happens if we run the article through an AI summarizer?
Here’s what
ellama-summarize-webpagegives me (I’m running Emacs integrated with an LLM running locally on my desktop):I kind of agree. Maybe dev.to should be a banned domain here.
I’m okay with that idea :)
On phone it takes up all of the screen. And clicking “okay” took me to the signup page. 😅
Hello. I am the author. I am sorry. I thought dev.to was a good platform for posting. Since them, I made a copy on a blog post without any advertising. https://benoittgt.github.io/blog/postgres_17_rails/
Sorry if my original reply seemed harsh - my issue was with dev.to, not at all with you or your article :) I’ve re-submitted your blog post to lobste.rs on the new URL :)
Thanks !
tl;dr? multiple IN expressions in a query now use indexes; you don’t have to write (a=? OR a=? OR a=?) you can just write a IN (?,?,?)
I haven’t used postgres seriously in a decade or more, so I’m unlikely to go change the one app I made once upon a time that still uses postgres to take advantage of this optimisation, but I clicked the link hoping to learn something anyway…
That seems to be it, and seems to be little more than a syntactic convenience when compared like this, but it could be significant if the new optimisation covers dynamic cases as well, like an ANY expression with a data-dependent array. Though even if it doesn’t work on dynamic cases, you could still say that a pitfall got ironed out.
That said, even though this post only mentions this IN optimisation, Postgres 17 does indeed seem to come with quite a lot of other optimiser improvements, seems significantly more than usual.
But how many of them had a baby-elephant sized ruby gemstone behind them?
So on Postgres <=16, is
WHERE column = val1 OR column = val2faster thanWHERE column IN ANY('{val1,val2}')given that the appropriate index exists?The major gain is when you are filtering on multiple in / =any.
https://pganalyze.com/blog/5mins-postgres-17-faster-btree-index-scans provides actual content.
It does also note a gain for single list predicates by avoiding an index query per value, and that can be significant if the list is large, but it’s not clear if scalars are affected or were optimised for this case and I don’t have a pg on hand to test.
I feel like the link should probably be replaced with this one, because it has actual content. The current one feels spammy and it barely has anything to do with Rails or Ruby.
Thanks a lot
(This was originally posted as a dev.to article, which wound up with the comments being 99% about how awful dev.to is, and 1% about the content itself. The author since reposted at their blog, so I thought it would make sense to submit the blog link instead).