Re: Do we need so many hint bits? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Do we need so many hint bits?
Date
Msg-id CA+U5nM+ptW9AxDYob0p5E1PoO4CtYWsCXcNzLaw5KxL5ZOmoag@mail.gmail.com
Whole thread Raw
In response to Re: Do we need so many hint bits?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Do we need so many hint bits?  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On 15 November 2012 22:21, Tom Lane <tgl@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

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: Re: [WIP] pg_ping utility
Next
From: Craig Ringer
Date:
Subject: Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY