Re: Berserk Autovacuum (let's save next Mandrill)

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Berserk Autovacuum (let's save next Mandrill)
Дата
Msg-id 7f4c22e2ddd742b083c71683b00f29bbd13a9b9d.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Berserk Autovacuum (let's save next Mandrill)  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Berserk Autovacuum (let's save next Mandrill)  (Laurenz Albe <laurenz.albe@cybertec.at>)
Re: Berserk Autovacuum (let's save next Mandrill)  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Fri, 2020-03-20 at 14:43 +0100, Laurenz Albe wrote:
> I.e. with the default settings we will perform a whole-index scan
> > (without visibility map or such) after every 10% growth of the
> > table. Which means that, even if the visibility map prevents repeated
> > tables accesses, increasing the rate of vacuuming for insert-only tables
> > can cause a lot more whole index scans.  Which means that vacuuming an
> > insert-only workload frequently *will* increase the total amount of IO,
> > even if there is not a single dead tuple. Rather than just spreading the
> > same amount of IO over more vacuums.
> > 
> > And both gin and gist just always do a full index scan, regardless of
> > vacuum_cleanup_index_scale_factor (either during a bulk delete, or
> > during the cleanup).  Thus more frequent vacuuming for insert-only
> > tables can cause a *lot* of pain (even an approx quadratic increase of
> > IO?  O(increased_frequency * peak_index_size)?) if you have large
> > indexes - which is very common for gin/gist.
> 
> In the light of that, I agree that we should increase the scale_factor.

Here is version 10 of the patch, which uses a scale factor of 0.2.

Yours,
Laurenz Albe

Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: is somewhere documented x LIKE ANY(ARRAY)?
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join