handling TOAST tables in autovacuum
От
Alvaro Herrera
Тема
handling TOAST tables in autovacuum
Дата
Msg-id
20080608230348.GD11028@alvh.no-ip.org
Список
Дерево обсуждения
handling TOAST tables in autovacuum Alvaro Herrera <alvherre@commandprompt.com>
Re: handling TOAST tables in autovacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: handling TOAST tables in autovacuum Alvaro Herrera <alvherre@commandprompt.com>
Re: handling TOAST tables in autovacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: handling TOAST tables in autovacuum Euler Taveira de Oliveira <euler@timbira.com>
Re: handling TOAST tables in autovacuum Alvaro Herrera <alvherre@commandprompt.com>
Re: handling TOAST tables in autovacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: handling TOAST tables in autovacuum Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Hi, We've been making noises about dealing with TOAST tables as separate entities in autovacuum for some time now. So here's a proposal: Let's do it. That's about it :-) The only change of some consideration is that we will need two passes over pg_class to get the list of relations to vacuum, instead of one as we do currently. The problem is that we first need to fetch the (heap relid, toast relid) mapping before attempting to figure out if any given TOAST table needs vacuuming. This is because we want to be using the main table's pg_autovacuum, and we can't get at that unless we know the main relid. Another open question is whether the TOAST table should be processed at all if the main table is vacuumed. My opinion is we don't -- if we're going to deal with them separately, let's go the whole nine yards. Autovacuum will only process a toast table when, by itself, it shows that it needs processing. (Obviously this doesn't mean we change semantics of user-invoked VACUUM -- those will continue to vacuum the TOAST table along the main table). Should we display TOAST tables separately in pg_stat_*_tables? (Maybe pg_stat_toast_tables?) Thoughts? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: