On Tue, Jan 18, 2011 at 12:32 PM, Jim Nasby <j...@nasby.net> wrote: >> How's that different from what vacuum does on a TOAST table now? > > TOAST vacuum is currently an entirely separate vacuum. It might run at the > same time as the main table vacuum, but it still has all the work that would > be associated with vacuuming a table with the definition of a toast table. In > fact, at one point vacuuming toast took two passes: the first deleted the > toast rows that were no longer needed, then you had to go back and vacuum > those deleted rows.
I don't know whether it still works that way or not, but if it does, fixing it could perhaps be done with far less drastic surgery than what you're proposing here. >>> Possibly, but you'd be paying tuple overhead twice, which is what I was >>> looking to avoid with forks. >> >> What exactly do you mean by "tuple overhead"? > > typedef struct HeapTupleHeaderData. With only two tables it might not be that > bad, depending on the fields. Beyond two tables it's almost certainly a loser. A struct definition by itself doesn't cause overhead. Are you talking about storage on disk? CPU usage for MVCC visibility testing? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
