Re: New GUC autovacuum_max_threshold ?

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: New GUC autovacuum_max_threshold ?
Дата
Msg-id c78950c4a37a29b62d4eede6ecc403ecdcd9eeb6.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: New GUC autovacuum_max_threshold ?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: New GUC autovacuum_max_threshold ?  (Frédéric Yhuel <frederic.yhuel@dalibo.com>)
Re: New GUC autovacuum_max_threshold ?  (Michael Banck <mbanck@gmx.net>)
Re: New GUC autovacuum_max_threshold ?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> I believe that the underlying problem here can be summarized in this
> way: just because I'm OK with 2MB of bloat in my 10MB table doesn't
> mean that I'm OK with 2TB of bloat in my 10TB table. One reason for
> this is simply that I can afford to waste 2MB much more easily than I
> can afford to waste 2TB -- and that applies both on disk and in
> memory.

I don't find that convincing.  Why are 2TB of wasted space in a 10TB
table worse than 2TB of wasted space in 100 tables of 100GB each?

> Another reason, at least in existing releases, is that at some
> point index vacuuming hits a wall because we run out of space for dead
> tuples. We *most definitely* want to do index vacuuming before we get
> to the point where we're going to have to do multiple cycles of index
> vacuuming.

That is more convincing.  But do we need a GUC for that?  What about
making a table eligible for autovacuum as soon as the number of dead
tuples reaches 90% of what you can hold in "autovacuum_work_mem"?

Yours,
Laurenz Albe



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: psql: add an optional execution-count limit to \watch.
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Improve the connection failure error messages