On Mon, Jul 15, 2013 at 1:41 PM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
