Re: visibilitymap_count() at the end of vacuum

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 ?

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee