Re: [HACKERS] GUC for cleanup indexes threshold.

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] GUC for cleanup indexes threshold.
Дата
Msg-id CAPpHfdt6J24Z8gVKExbr-tbwQW5sX9ECfNKGLN=U=JfALBXOug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GUC for cleanup indexes threshold.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] GUC for cleanup indexes threshold.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Fri, Mar 2, 2018 at 10:53 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 2) In the append-only case, index statistics can lag indefinitely.

The original proposal proposed a new GUC that specifies a fraction of
the modified pages to trigger a cleanup indexes.

Regarding original proposal, I didn't get what exactly it's intended to be.
You're checking if vacuumed_pages >= nblocks * vacuum_cleanup_index_scale.
But vacuumed_pages is the variable which could be incremented when
no indexes exist on the table.  When indexes are present, this variable is always
zero.  I can assume, that it's intended to compare number of pages where
at least one tuple is deleted to nblocks * vacuum_cleanup_index_scale.
But that is also not an option for us, because we're going to optimize the
case when exactly zero tuples is deleted by vacuum.

The thing I'm going to propose is to add estimated number of tuples in
table to IndexVacuumInfo.  Then B-tree can memorize that number of tuples
when last time index was scanned in the meta-page.  If pass value
is differs from the value in meta-page too much, then cleanup is forced.

Any better ideas?


------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: perltidy version
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #14941: Vacuum crashes