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!
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? |