Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > 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.
>
> Umm ... is it chiseled in stone someplace that toast tables shouldn't
> have their own pg_autovacuum entries? Seems like that might be a
> reasonable component of a "whole nine yards" approach.
No, but I think it's a bit awkward for users to follow _only_ its own
entry. I forgot to mention that in the patch I currently have, what
autovacuum does is try to get the TOAST table's own pg_autovacuum entry,
and if that fails, get the main rel's entry.
The point here is that if the user disables autovac for the main table,
then it's expected that it is automagically disabled for the toast table
as well, for the usual case where they are disabling it because the
table is too big. Automatically processing the toast table would be
completely unexpected, and most likely unwelcome.
Of course, for the even rarer cases when you want to disable it for the
main rel and enable it for the toast table, you can do that too. (I
can't think of a case where this would be useful though.)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.