Re: Indexes on expressions with multiple columns and operators
От | Frédéric Yhuel |
---|---|
Тема | Re: Indexes on expressions with multiple columns and operators |
Дата | |
Msg-id | 493a013c-63d1-467a-b9ec-352f77baf37a@dalibo.com обсуждение исходный текст |
Ответ на | Re: Indexes on expressions with multiple columns and operators (Andrei Lepikhov <lepihov@gmail.com>) |
Ответы |
Re: Indexes on expressions with multiple columns and operators
|
Список | pgsql-performance |
On 9/22/25 15:57, Andrei Lepikhov wrote: > On 22/9/2025 15:37, Frédéric Yhuel wrote: >> I wonder if this is an argument in favour of decoupling the sample >> size and the precision of the statistics. Here, we basically want the >> sample size to be as big as the table in order to include the few >> (NULL, WARNING) values. > I also have seen how repeating ANALYZE on the same database drastically > changes query plans ;(. > It seems to me that with massive samples, many of the ANALYZE algorithms > should be rewritten. In principle, statistical hooks exist. So, it is > possible to invent an independent table analyser which will scan the > whole table to get precise statistics. > Interesting! I wonder how difficult it would be. However, in this specific case, I realised that it wouldn't solve the issue of ANALYZE being triggered when there are zero rows with (ackid, crit) = (NULL, WARNING). Partitioning would still work in this case, though, because ackid's null_frac would be zero for the partition containing the 'WARNING' value. I wonder if we could devise another kind of extended statistic that would provide these "partitioned statistics" without actually partitioning.
В списке pgsql-performance по дате отправления: