Re: Indexes on expressions with multiple columns and operators
Frédéric Yhuel <frederic.yhuel@dalibo.com>
From: Frédéric Yhuel <frederic.yhuel@dalibo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-performance@lists.postgresql.org"
<pgsql-performance@lists.postgresql.org>,
Jehan-Guillaume de Rorthais <jgdr@dalibo.com>,
Christophe Courtois <christophe.courtois@dalibo.com>,
Laurenz Albe <laurenz.albe@cybertec.at>
Date: 2025-09-22T13:37:23Z
Lists: pgsql-performance
On 9/20/25 18:51, Tom Lane wrote: > I concluded that maybe I was overthinking this part. We only really > need to check the rowcount estimate, since the indexscan cost estimate > is already okay. And stats_ext.sql seems to have gotten away with > assuming that rowcount estimates are reliably reproducible on > not-too-large tables. This bug affects use of extended statistics > too, so a test using those is good enough to show it's fixed; we don't > really need to use an expression index for the purpose. So, I added a > test case in stats_ext.sql and pushed it. OK, great! Thanks for the detailed explanation. Regarding extended statistics, it's unfortunate that they cannot be used in this case. Multivariate MCV statistics work as long as the number of rows in the table is reasonably small (100K) and the STATISTICS value for a column is high enough (it doesn't matter which column, because only the sample size matters). I wonder if this is an argument in favour of decoupling the sample size and the precision of the statistics. Here, we basically want the sample size to be as big as the table in order to include the few (NULL, WARNING) values. Or maybe we need a different kind of extended statistics?
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Re-allow using statistics for bool-valued functions in WHERE.
- 1eccb9315070 19 (unreleased) landed
-
Build out the planner support function infrastructure.
- a391ff3c3d41 12.0 cited
-
Allow planner to use expression-index stats for function calls in WHERE.
- 39df0f150ca6 9.6.0 cited