Horton
Menu

Re: Indexes on expressions with multiple columns and operators

Frédéric Yhuel <frederic.yhuel@dalibo.com>

View thread
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-23T13:31:18Z
Lists: pgsql-performance 

On 9/23/25 12:43, Andrei Lepikhov wrote:
> But is it the same for the 'distinct' statistics? It seems you should 
> love it - the number of groups in GROUP-BY, DISTINCT, and even HashJoin 
> should be estimated more precisely, no?

I think it has more potential, and I would love to use this weapon, but 
I haven't had the opportunity yet. It would be interesting to know how 
much it is used in real life.

To get back to the topic of partitioned statistics, do you know if SQL 
Server is smart enough to handle this case [1] that we discussed last 
year? (with filtered statistics)

[1] 
https://www.postgresql.org/message-id/flat/b860c71a-7cab-4d88-ad87-8c1f2eea9ae8%40dalibo.com

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.