Re: visibilitymap_count() at the end of vacuum

On Tuesday, December 04, 2012 5:14 AM Pavan Deolasee wrote:
On Tue, Dec 4, 2012 at 3:16 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>>Also, if someone does have a 100GB relation, rereading 2MB of
>>visibility map pages at the end probably isn't a significant part of
>>the total cost.  Even if 99.9% of the relation is all-visible and we
>>skip reading those parts, the visibility map reads will still be only
>>about 2% of the total read activity, and most of the time you won't be
>>that lucky.

>Hmm. I fully agree its a very small percentage of the total cost. But I
still don't see why it should not be optimised, if possible. Of >course, if
not recounting at the end will generate bad query plans most of the time for
most of the workloads or even a few workloads, >then the minuscule cost will
pay of. But nobody convincingly argued about that.

>Even if the current way is the right way, we should probably just add a
comment there. I also noticed that we call vacuum_delay_point() >after
testing every visibility map bit in lazy_scan_heap() which looks overkill,
but visibilitymap_count() runs to the end without even a >single call to
vacuum_delay_point(). Is that intended ? Or should we at least check for
interrupts there ?

I think calling vacuum_delay_point(), after every visibility map bit test in
lazy_scan_heap() might not be necessary.
Shouldn't both places be consistent and call vacuum_delay_point() after one
vm page processing?

With Regards,
Amit Kapila.