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)
Re: Berserk Autovacuum (let's save next Mandrill) |
Список | 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 по дате отправления: