Re: autovacuum stress-testing our system
От | Tomas Vondra |
---|---|
Тема | Re: autovacuum stress-testing our system |
Дата | |
Msg-id | 50A96B91.1050409@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: autovacuum stress-testing our system (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 26.9.2012 18:29, Tom Lane wrote: > What seems to me like it could help more is fixing things so that the > autovac launcher needn't even launch a child process for databases that > haven't had any updates lately. I'm not sure how to do that, but it > probably involves getting the stats collector to produce some kind of > summary file. Couldn't we use the PgStat_StatDBEntry for this? By splitting the pgstat.stat file into multiple pieces (see my other post in this thread) there's a file with StatDBEntry items only, so maybe it could be used as the summary file ... I've been thinking about this: (a) add "needs_autovacuuming" flag to PgStat_(TableEntry|StatDBEntry) (b) when table stats are updated, run quick check to decide whether the table needs to be processed by autovacuum (vacuumedor analyzed), and if yes then set needs_autovacuuming=true and both for table and database The worker may read the DB entries from the file and act only on those that need to be processed (those with needs_autovacuuming=true). Maybe the DB-level field might be a counter of tables that need to be processed, and the autovacuum daemon might act on those first? Although the simpler the better I guess. Or did you mean something else? regards Tomas
В списке pgsql-hackers по дате отправления: