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

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Berserk Autovacuum (let's save next Mandrill)
Дата
Msg-id 9c9b7d19d17ad5e4e0ee10b8426fa1b78dd24c0a.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Berserk Autovacuum (let's save next Mandrill)  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Berserk Autovacuum (let's save next Mandrill)  (Andres Freund <andres@anarazel.de>)
Re: Berserk Autovacuum (let's save next Mandrill)  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Mon, 2020-03-16 at 07:47 -0500, Justin Pryzby wrote:
> It seems to me that the easy thing to do is to implement this initially without
> FREEZE (which is controlled by vacuum_freeze_table_age), and defer until
> July/v14 further discussion and implementation of another GUC/relopt for
> autovacuum freezing to be controlled by insert thresholds (or ratio).

Freezing tuples is the point of this patch.
As I have said, if you have a table where you insert many rows in few
transactions, you would trigger an autovacuum that then ends up doing nothing
because none of the rows have reached vacuum_freeze_table_age yet.

Then some time later you will get a really large vacuum run.

It seems to me that if we keep trying finding the formula that will vacuum
every table just right and never so the wrong thing, we will never get to anything.

Yours,
Laurenz Albe




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

Предыдущее
От: legrand legrand
Дата:
Сообщение: Re: Planning counters in pg_stat_statements (using pgss_store)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Berserk Autovacuum (let's save next Mandrill)