| 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 13:31:18 |
| Message-ID: | d701cab9-c7c9-44f7-ac10-d17ed78bedbb@dalibo.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 9/23/25 12:43, Andrei Lepikhov wrote:
> But is it the same for the 'distinct' statistics? It seems you should
> love it - the number of groups in GROUP-BY, DISTINCT, and even HashJoin
> should be estimated more precisely, no?
I think it has more potential, and I would love to use this weapon, but
I haven't had the opportunity yet. It would be interesting to know how
much it is used in real life.
To get back to the topic of partitioned statistics, do you know if SQL
Server is smart enough to handle this case [1] that we discussed last
year? (with filtered statistics)
[1]
https://www.postgresql.org/message-id/flat/b860c71a-7cab-4d88-ad87-8c1f2eea9ae8%40dalibo.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dirschel, Steve | 2025-09-23 19:40:40 | Very expensive update to update a single row |
| Previous Message | Andrei Lepikhov | 2025-09-23 10:43:32 | Re: Indexes on expressions with multiple columns and operators |