On Thu, Nov 15, 2012 at 10:37 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 15 November 2012 22:21, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Removing those 3 hints would give us 3 more flag bits (eventually, after >>> we are sure they aren't just leftover), and it would also reduce the >>> chance that a page is dirtied for no other reason than to set them. >> >> We aren't pressed for flag bits particularly. I think the main >> attraction of this idea is precisely to reduce unnecessary page dirties, >> and so that leads me to suggest a variant: keep the four bits defined as >> now, but do not attempt to set XMIN_INVALID or XMAX_COMMITTED unless the >> page is already dirty. This would make it a straight-up trade of more >> clog consultation for fewer page dirties. > > Hmm, I thought Alvaro wanted an extra flag bit for foreign key locks > but couldn't find it. > > Come to think of it, why do we have XMIN_INVALID and XMAX_INVALID? We > never need both at the same time, so we can just use one... > XMIN_INVALID -> XACT_INVALID > XMAX_INVALID == XMIN_COMMITTED | XACT_INVALID
Hm, I wonder if you could squeeze two bits out. ISTM here are the interesting cases enumerated: 0: xmin unknown 1: xmin invalid 2: xmin valid, xmax unknown 3: xmin valid, xmax invalid 4: xmin valid, xmax valid Did I miss any? If not, I think case #3 could be covered by utilizing xmax == InvalidTransactionId or simply ignored. That makes the check a little dirtier than a bit test though, but you could be sneaky and map both xmin=valid cases to a bit. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers