Re: Autovacuum on partitioned table (autoanalyze)
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Autovacuum on partitioned table (autoanalyze) |
| Дата | |
| Msg-id | 202108102138.rmo2pbphkkqs@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: Autovacuum on partitioned table (autoanalyze) (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | pgsql-hackers |
On 2021-Aug-10, Alvaro Herrera wrote: > I bring a radical proposal that may be sufficient to close this > particular hole. What if we made partition only affected their > top-level parents to become auto-analyzed, and not any intermediate > ancestors? Any intermediate partitioned partitions could be analyzed > manually if the user wished, and perhaps some reloption could enable > autovacuum to do it (with the caveat that it'd cause multiple sampling > of partitions). I don't yet have a clear picture on how to implement > this, but I'll explore it while waiting for opinions on the idea. So, with this patch (a quick and dirty job) we no longer sample all partitions twice; we no longer propagate the tuple counts to p_0. We don't have stats on p_0 anymore, only on p and on the individual partitions. I didn't move the new #include to a more decent place because 1. that stuff is going to move to partition.c as a new function, including the new include; 2. that new function also needs to read the reloptions for p_0 to allow the user to enable stat acquisition for p_0 with "alter table p_0 set (autovacuum_enabled=1)"; 3. need to avoid reporting ancestors of a partition repeatedly, which forestalls the performance objection about reading reloptions too frequently. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Вложения
В списке pgsql-hackers по дате отправления: