Re: Avoiding second heap scan in VACUUM

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: "Postgres - Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoiding second heap scan in VACUUM
Date: 2008-05-28 17:55:27
Message-ID: 877ideqpo0.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)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!

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-05-28 18:22:36 Re: BUG #4204: COPY to table with FK has memory leak
Previous Message Tom Lane 2008-05-28 15:20:04 Re: Remove redundant extra_desc info for enum GUC variables?