Re: Avoiding second heap scan in VACUUM - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Avoiding second heap scan in VACUUM
Date
Msg-id 877ideqpo0.fsf@oxford.xeocode.com
Whole thread Raw
In response to Avoiding second heap scan in VACUUM  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:

> 1. Before VACUUM starts, it updates the pg_class row of the target
> table, noting that VACUUM_IN_PROGRESS for the target table.

If I understand correctly nobody would be able to re-use any line-pointers
when a vacuum is in progress? I find that a bit scary since for large tables
you may actually always be running a vacuum. Perhaps the DSM will fix that but
for heavily updated tables I think you might still be pretty much continuously
running vacuum. 

On the other hand it would just result in line pointer bloat. And I think
VACUUM could still safely remove old dead line pointers if it noted that the
table had a clean vacuum status when it started.

> 2. It then waits for all the existing transactions to finish to make
> sure that everyone can see the change in the pg_class row,

I'm a bit scared of how many "waits for all transactions to finish" we're
accumulating. It seemed safe enough when we had only one but I'm not sure what
the consequences for this action are when there are several of them. Are we
perhaps creating deadlocks?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Remove redundant extra_desc info for enum GUC variables?
Next
From: Gregory Stark
Date:
Subject: Re: BUG #4204: COPY to table with FK has memory leak