Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
  Ask me about EnterpriseDB's PostGIS support!

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group