On Wed, 2013-05-29 at 22:46 -0400, Robert Haas wrote:
> Again independently of Josh's proposal, we could eliminate
> PD_ALL_VISIBLE. This would require either surrendering the
> optimization whereby sequential scans can skip visibility checks on
> individual tuples within the page, or referring to the visibility map
> to get the bit that way. I know you tested this and couldn't measure
> an impact, but with all respect I find that result hard to accept.
> Contention around buffer locks and pins is very real; why should it
> matter on other workloads and not matter on this one?
The number of pins required during a sequential scan without my patch
is:
PAGES_IN_HEAP
The number of pins required during a sequential scan with my patch is:
PAGES_IN_HEAP + ceil(PAGES_IN_HEAP/HEAP_PAGES_PER_VM_PAGE)
Because HEAP_PAGES_PER_VM_PAGE is huge, the second term only matters
when N is very small and the "ceil" is significant. So, I simply elected
not to use the VM if the table is less than 32 pages in size. For such
small tables, the benefit of using a page-at-a-time visibility check was
not apparent in my tests anyway.
> AFAICS, the main benefit of eliminating PD_ALL_VISIBLE is that we
> eliminate one write cycle; that is, we won't dirty the page once to
> hint it and then again to mark it all-visible. But as of 9.3, that
> should really only be a problem in the insert-only case. And in that
> case, my proposal to consider all-visible pages as frozen would be a
> huge win, because you'd only need to emit XLOG_HEAP_VISIBLE for every
> page in the heap, rather than XLOG_HEAP_FREEZE.
Agreed.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
