Horton
Menu

Re: Indexes on expressions with multiple columns and operators

Jehan-Guillaume de Rorthais <jgdr@dalibo.com>

View thread
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>, "pgsql-performance@lists.postgresql.org" <pgsql-performance@lists.postgresql.org>, Christophe Courtois <christophe.courtois@dalibo.com>, Laurenz Albe <laurenz.albe@cybertec.at>
Date: 2025-09-19T14:37:45Z
Lists: pgsql-performance 
On Thu, 18 Sep 2025 12:59:11 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Jehan-Guillaume de Rorthais <jgdr@dalibo.com> writes:
> > On a fresh instance from HEAD with its default configuration, it shows:
> 
> >   Index Scan using foo_s_idx on foo  (cost=0.29..8.39 rows=33333 width=13)
> >     Index Cond: (s(crit, ackid) = true)
> 
> > It seems statistics shown in "pg_stats" view for function "s()" are good.
> > The query itself even have the same costs than the query using the syntax
> > tips you provide before.
> 
> > However, the estimated row number seems wrong in regard with the costs shown
> > and statistics.
> 
> Yeah.  The problem is that clause_selectivity_ext fails to consider
> use of statistics if the clause looks like "bool_valued_function(...)".
> If it looks like "bool_valued_function(...) = true", that goes down
> a different code path that does the right thing.

Oh, OK, I understand.

Thanks for your explanations!

Regards,

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.