Re: shared memory stats: high level design decisions: consistency, dropping

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: shared memory stats: high level design decisions: consistency, dropping
Дата
Msg-id 20210324085114.GA13377@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: shared memory stats: high level design decisions: consistency, dropping  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 2021-Mar-21, Andres Freund wrote:

> We currently also fetch the full stats in places like autovacuum.c. Where we
> don't need repeated access to be consistent - we even explicitly force the
> stats to be re-read for every single table that's getting vacuumed.
> 
> Even if we to just cache already accessed stats, places like do_autovacuum()
> would end up with a completely unnecessary cache of all tables, blowing up
> memory usage by a large amount on systems with lots of relations.

It's certainly not the case that autovacuum needs to keep fully
consistent stats.  That's just the way that seemed easier (?) to do at
the time.  Unless I misunderstand things severely, we could just have
autovacuum grab all necessary numbers for one database at the start of a
run, not cache anything, then re-read the numbers for one table as it
rechecks that table.

Resetting before re-reading was obviously necessary because the
built-in snapshotting made it impossible to freshen up the numbers at
the recheck step.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W



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

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: Disable WAL logging to speed up data loading
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?