From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>, Christophe Courtois <christophe(dot)courtois(at)dalibo(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Subject: | Re: Indexes on expressions with multiple columns and operators |
Date: | 2025-09-19 14:37:45 |
Message-ID: | 20250919163745.1dfc1044@karst |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 18 Sep 2025 12:59:11 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)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,
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Long | 2025-09-19 18:26:59 | Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column |
Previous Message | Andrei Lepikhov | 2025-09-19 07:50:41 | Re: Why isn't PG using an index-only scan? |