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: Andrei Lepikhov <lepihov@gmail.com>, 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-23T10:20:44Z
Lists: pgsql-performance
On 9/22/25 23:15, Andrei Lepikhov wrote: > I'm not sure I fully understand your case, but SQL Server demonstrates > an interesting approach: they have a WHERE clause attached to > statistics. So, having implemented this, you may separate the whole > range of values inside the table into 'partitions' by such a WHERE > condition. Yes, from what I understood of the documentation [1], this is exactly what I would like! > It may solve at least one issue with the 'dependencies' statistics: a > single number describing the dependency between any two values in the > columns often leads to incorrect estimations, as I see. For what it's worth, I've never encountered a case in my life as a PostgreSQL support engineer where the 'dependency' kind could be useful. I only successfully used the 'mcv' kind once (and that was only partially successful, as it fixed the estimates but not the plan). [1] https://learn.microsoft.com/en-us/sql/t-sql/statements/create-statistics-transact-sql?view=sql-server-ver17#c-use-create-statistics-to-create-filtered-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