From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
---|---|
To: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, 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-23 10:20:44 |
Message-ID: | c7304dbd-ce2a-40c8-b267-d2c95abfc36e@dalibo.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 9/22/25 23:15, Andrei Lepikhov wrote:
> I'm not sure I fully understand your case, but SQL Server demonstrates
> an interesting approach: they have a WHERE clause attached to
> statistics. So, having implemented this, you may separate the whole
> range of values inside the table into 'partitions' by such a WHERE
> condition.
Yes, from what I understood of the documentation [1], this is exactly
what I would like!
> It may solve at least one issue with the 'dependencies' statistics: a
> single number describing the dependency between any two values in the
> columns often leads to incorrect estimations, as I see.
For what it's worth, I've never encountered a case in my life as a
PostgreSQL support engineer where the 'dependency' kind could be useful.
I only successfully used the 'mcv' kind once (and that was only
partially successful, as it fixed the estimates but not the plan).
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-09-23 10:43:32 | Re: Indexes on expressions with multiple columns and operators |
Previous Message | Andrei Lepikhov | 2025-09-22 21:15:52 | Re: Indexes on expressions with multiple columns and operators |