From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: visibilitymap_count() at the end of vacuum |
Date: | 2012-12-03 18:20:20 |
Message-ID: | 20121203182020.GA16057@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2012-12-03 23:44:36 +0530, Pavan Deolasee wrote:
> I wonder if we really need to make another pass over the entire visibility
> map to count the number of all-visible pages at the end of the vacuum. The
> code that I'm looking at is in src/backend/commands/vacuumlazy.c:
>
> 247 new_rel_allvisible = visibilitymap_count(onerel);
> 248 if (new_rel_allvisible > new_rel_pages)
> 249 new_rel_allvisible = new_rel_pages;
>
> We would have just scanned every bit of the visibility map and can remember
> information about the number of all-visible pages in vacrelstats, just like
> many other statistical information that we track and update the end of the
> vacuum. Sure, there might be some more updates to the VM, especially a few
> bits may get cleared while we are vacuuming the table, but that can happen
> even while we are recounting at the end. AFAICS we can deal with that much
> staleness of the data.
A full-table vacuum can take a *long* (as in days) time, so I think
recounting makes sense. And normally the cost is pretty small, so I
don't see a problem in this.
Why change it?
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2012-12-03 18:36:16 | Re: visibilitymap_count() at the end of vacuum |
Previous Message | Pavan Deolasee | 2012-12-03 18:14:36 | visibilitymap_count() at the end of vacuum |