| From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, 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-17 15:33:35 |
| Message-ID: | 9a3389fe-fbc8-4e40-9a35-691bc35d043d@dalibo.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 9/17/25 16:57, Frédéric Yhuel wrote:
> Yes, Laurenz made a similar suggestion, but the problem is that I'm
> mostly interested in the estimated number of output rows... because in
> the real query, there's a very bad Hash Join above (the Nested Loop is
> *much* faster).
BTW, I've also tested another solution: partitioning on 'criticity',
with one partition for 'INFO' (99% of the rows), and another one for the
other values ('WARNING' and 'ALARM' in the real case). The statistics
are much better... however an expression index would be an easier fix.
Multivariate MCV statistics don't work well in the real case (100M lines
in the table).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jean-Christophe BOGGIO | 2025-09-18 06:36:25 | Why isn't PG using an index-only scan? |
| Previous Message | Frédéric Yhuel | 2025-09-17 14:57:26 | Re: Indexes on expressions with multiple columns and operators |