On Thu, Jul 27, 2017 at 10:05 PM, Peter Geoghegan <p...@bowt.ie> wrote: > I really don't know if that would be worthwhile. It would certainly fix > the regression shown in my test case, but that might not go far enough. > I strongly suspect that there are more complicated workloads where > LP_DEAD cleanup from SELECT statements matters, which is prevented by > the LSN check thing, just because there are always other sessions that > modify the page concurrently. This might be true of Alik's Zipfian test > case, for example.
I haven't studied the test case, but I think as a general principle it makes sense to be happy when someone comes up with an algorithm that holds a lock for a shorter period of time (and buffer pins are a type of lock). There are a number of places (fast-path locking, for example, or vacuum skipping pinned heap pages) where we have fast-paths that get taken most of the time and slow paths that get used when concurrent activity happens; empirically, such things often work out to a win. I think it's disturbing that this code seems to be taking the slow-path (which, in context, means skipping LP_DEAD cleanup) even there is no concurrent activity. That's hard to justify. But the fact that it is taking the slow-path when there *is* concurrent activity is harder to complain about. That might win or it might lose; the non-concurrent case only loses. -- 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
