On Mon, Jul 15, 2013 at 1:41 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> I'm of the opinion that we ought to extract the parts of the patch
>> that hold the VM pin for longer, review those separately, and if
>> they're good and desirable, apply them.
>
> I'm confused. My patch holds a VM page pinned for those cases where
> PD_ALL_VISIBLE is currently used -- scans or insert/update/delete. If we
> have PD_ALL_VISIBLE, there's no point in the cache, right?
Hmm. You might be right. I thought there might be some benefit
there, but I guess we're not going to clear the bit more than once, so
maybe not.
> To check visibility from an index scan, you either need to pin a heap
> page or a VM page. Why would checking the heap page be cheaper? Is it
> just other code in the VM-testing path that's slower? Or is there
> concurrency involved in your measurements which may indicate contention
> over VM pages?
Well, I have seen some data that hints at contention problems with VM
pages, but it's not conclusive. But the real issue is that, if the
index-only scan finds the VM page not set, it still has to check the
heap page. Thus, it ends up accessing two pages rather than one, and
it turns out that's more expensive. It's unfortunately hard to
predict whether the cost of checking VM first will pay off. It's a
big win if we learn that we don't need to look at the heap page
(because we don't need to read, lock, pin, or examine it, in that
case) but it's a loss if we do (because checking the VM isn't free).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company