Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column

2025-09-19 Thread Tom Lane
Matt Long writes: > I finally got around to testing your patch on a realistic data set. In > short, the patch worked beautifully even with the division by 2 removed. In > case it's helpful, the full write up of my investigation can be found at > https://gist.github.com/mattlong/0617bec6e1cf5bc6b70

Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column

2025-09-19 Thread Matt Long
I finally got around to testing your patch on a realistic data set. In short, the patch worked beautifully even with the division by 2 removed. In case it's helpful, the full write up of my investigation can be found at https://gist.github.com/mattlong/0617bec6e1cf5bc6b70c6c2951901df7 Your reasoni

Re: Indexes on expressions with multiple columns and operators

2025-09-19 Thread Jehan-Guillaume de Rorthais
On Thu, 18 Sep 2025 12:59:11 -0400 Tom Lane wrote: > Jehan-Guillaume de Rorthais writes: > > On a fresh instance from HEAD with its default configuration, it shows: > > > Index Scan using foo_s_idx on foo (cost=0.29..8.39 rows=3 width=13) > > Index Cond: (s(crit, ackid) = true) > >

Re: Why isn't PG using an index-only scan?

2025-09-19 Thread Andrei Lepikhov
On 19/9/2025 03:05, David Rowley wrote: On Thu, 18 Sept 2025 at 23:55, Andrei Lepikhov wrote: Perhaps we should start working on introducing this type of callback/ hook? There's certainly places where you could add a hook that would just add an unacceptable overhead that we couldn't stomach. I

Re: Indexes on expressions with multiple columns and operators

2025-09-19 Thread Frédéric Yhuel
On 9/18/25 18:40, Tom Lane wrote: The attached fixes things so it works like it did pre-a391ff3c3. Indeed, it works well! I spent some time trying to devise a test case, and was reminded of why I didn't have one before: it's hard to make a case that will be robust enough to not show diffs