Re: [HACKERS] GUC for cleanup indexes threshold.
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] GUC for cleanup indexes threshold. |
Дата | |
Msg-id | CA+TgmoavbPU+1rV-2fMh3+9uAPP5=c9MooJmMCSTJmCQNGLg1A@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] GUC for cleanup indexes threshold. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Wed, Jan 4, 2017 at 3:21 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > Hi and happy new year. > > The lazy vacuum calls lazy_cleanup_index to update statistics of > indexes on a table such as relpages, reltuples at the end of the > lazy_scan_heap. In all type of indexes the lazy_cleanup_index scans > all index pages. It happens even if table has not been updated at all > since previous vacuum invoked. Freeze map reduces the execution time > and cost of table vacuuming much if almost table has been frozen. But > it doesn't work for cleaning up indexes. If a very large static table > has index then because the cleaning up index is called and it always > scans all index pages, it takes time to scan all pages of index as > reported[1]. > > Attached patch introduces new GUC parameter parameter > vacuum_cleanup_index_scale_factor which specifies the fraction of the > table pages containing dead tuple needed to trigger a cleaning up > indexes. The default is 0.0, which means that the cleanup index is not > invoked if no update on table. In other word, if table is completely > frozen then lazy vacuum can skip the index scans as well. Increasing > this value could reduce total time of lazy vacuum but the statistics > and the free space map of index are not updated. Cool. I'll look at this, but not until next CF. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: