Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
>> The main bit of additional logic that might be needed is an awareness
>> that firing a VACUUM on a main table will implicitly fire one on its
>> toast table, and so you'd not want to go and issue the toast table
>> VACUUM separately.
> I don't see any reason why this wouldn't work. I even think it'd be
> very easy to implement (from the autovacuum POV -- not sure about the
> stat system). Furthermore, the awareness you mention is also very easy
> to implement: we just need to make sure the pg_autovacuum tuple for the
> toast table is updated when it is vacuumed, which is just an additional
> function call.
I'm having some second thoughts about allowing VACUUM on a toast table
independently of its parent table --- it's a bit scary to be messing
with the toast table when we have no lock at all on the parent. It
might work OK, but I'm not sure I want to take the risk. If we simply
expose toast tables in the stats views, what has to be done to
autovacuum to get it to work properly? ("Properly" in this case would
mean "fire a VACUUM on the parent table if either it or its toast table
look like they need vacuumed".) Is this much worse than what you
say above?
> Have you looked at the autovacuum integration patch?
No, but will do.
regards, tom lane
