On Thu, 2013-04-04 at 22:39 +0200, Andres Freund wrote: > I don't think its really slower. Earlier the code took WalInsertLock > everytime, even if we ended up not logging anything. Thats far more > epensive than a single spinlock. And the copy should also only be taken > in the case we need to log. So I think we end up ahead of the current > state.
Good point. > > The code looks good to me except that we should be consistent about the > > page hole -- XLogCheckBuffer is calculating it, but then we copy the > > entire page. I don't think anything can change the size of the page hole > > while we have a shared lock on the buffer, so it seems OK to skip the > > page hole during the copy. > > I don't think it can change either, but I doubt that there's a > performance advantage by not copying the hole. I'd guess the simpler > code ends up faster. I was thinking more about the WAL size, but I don't have a strong opinion. 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