Re: Indexes on expressions with multiple columns and operators

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>, "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-10-13T14:55:07Z
Lists: pgsql-performance
Andrei Lepikhov <lepihov@gmail.com> writes:
> On 25/9/2025 12:41, Frédéric Yhuel wrote:
>> So, on SQL Server, you can do this:
>> CREATE STATISTICS FooStats ON foo (ackid, crit) WHERE crit = 'WARNING';

> Nice! Thanks for the report. I think the only reason why Postgres 
> doesn't have it yet is the computational cost.

I think it's more lack of round tuits.  If we had such an option for
statistics objects, presumably we'd determine the applicability of a
particular statistics object to a query the same way we do for partial
indexes, namely try to prove the statistics' restriction condition
from the query WHERE clauses.  I've not heard complaints about that
being unduly expensive.

In the meantime, I believe the old-fashioned approach of creating
a partial expression index and letting ANALYZE collect stats on that
will serve, at least for simple statistics.

			regards, tom lane



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.