From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | visibilitymap_count() at the end of vacuum |
Date: | 2012-12-03 18:14:36 |
Message-ID: | CABOikdMqd4rgv9YP4R=LQs77wwn4ixG+1OVmGQLVVEUAQOa5Dg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
If we agree that this is worth improving, I can write a patch to do so.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-03 18:20:20 | Re: visibilitymap_count() at the end of vacuum |
Previous Message | Andrew Dunstan | 2012-12-03 18:14:30 | Re: Tablespaces in the data directory |