On Wed, May 11, 2016 at 12:30 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-05-11 12:27:55 -0400, Robert Haas wrote: >> On Wed, May 11, 2016 at 11:49 AM, Andres Freund <and...@anarazel.de> wrote: >> > On 2016-05-11 10:12:26 -0400, Robert Haas wrote: >> >> > Hm. Do we really have to keep the page locked in the page-at-a-time >> >> > mode? Shouldn't the pin suffice? >> >> >> >> I think we need a lock to examine MVCC visibility information. A pin >> >> is enough to prevent a tuple from being removed, but not from having >> >> its xmax and cmax overwritten at almost but not quite exactly the same >> >> time. >> > >> > We already batch visibility lookups in page-at-a-time >> > mode. Cf. heapgetpage() / scan->rs_vistuples. So we can evaluate quals >> > after releasing the lock, but before the pin is released, without that >> > much effort. IIRC that isn't used for index lookups, but that's >> > probably a good idea. >> >> The trouble with that is that if you fail the qual, you have to relock >> the page. Which kinda sucks, if the qual is really simple. > > Hm? I'm missing something here? We currently do the visibility checks in > bulk for the whole page. After that we release the page lock. What > prevents us from executing the quals directly after that? And why would > you need to relock the page?
Oh, yeah, in page-at-a-time mode we can release the lock first. I was thinking at what to do in tuple-at-a-time mode (i.e. when the page is not all-visible). -- 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