Re: We probably need autovacuum_max_wraparound_workers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: We probably need autovacuum_max_wraparound_workers
Дата
Msg-id 26822.1340849902@sss.pgh.pa.us
обсуждение исходный текст
Ответ на We probably need autovacuum_max_wraparound_workers  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: We probably need autovacuum_max_wraparound_workers  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> Yeah, I can't believe I'm calling for *yet another* configuration
> variable either.  Suggested workaround fixes very welcome.

> The basic issue is that autovacuum_max_workers is set by most users
> based on autovac's fairly lightweight action most of the time: analyze,
> vacuuming pages not on the visibility list, etc.  However, when XID
> wraparound kicks in, then autovac starts reading entire tables from disk
> ... and those tables may be very large.

It doesn't seem to me that this has much of anything to do with
wraparound; that just happens to be one possible trigger condition
for a lot of vacuuming activity to be happening.  (Others are bulk
data loads or bulk updates, for instance.)  Nor am I convinced that
changing the max_workers setting is an appropriate fix anyway.

I think what you've really got here is inappropriate autovacuum cost
delay settings, and/or the logic in autovacuum.c to try to divvy up the
available I/O capacity by tweaking workers' delay settings isn't working
very well.  It's hard to propose improvements without a lot more detail
than you've provided, though.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Следующее
От: David Johnston
Дата:
Сообщение: Re: We probably need autovacuum_max_wraparound_workers