| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| 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>, 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-10-13 14:55:07 |
| Message-ID: | 228091.1760367307@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Andrei Lepikhov <lepihov(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2025-10-14 09:29:27 | Re: Indexes on expressions with multiple columns and operators |
| Previous Message | Andrei Lepikhov | 2025-10-13 14:00:35 | Re: Indexes on expressions with multiple columns and operators |