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 →
  1. Re-allow using statistics for bool-valued functions in WHERE.

  2. Build out the planner support function infrastructure.

  3. Allow planner to use expression-index stats for function calls in WHERE.