Skip site navigation (1) Skip section navigation (2)

Re: Do we need so many hint bits?

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Do we need so many hint bits?
Date: 2012-11-16 14:58:27
Message-ID: 20121116145827.GD6505@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2012-11-16 08:43:12 -0600, Merlin Moncure wrote:
> On Thu, Nov 15, 2012 at 9:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> >> It occurred to me recently that many of the hint bits aren't terribly
> >> important (at least it's not obvious to me). HEAP_XMIN_COMMITTED clearly
> >> has a purpose, and we'd expect it to be used many times following the
> >> initial CLOG lookup.
> >
> > Right.
> >
> >> But the other tuple hint bits seem to be there just for symmetry,
> >> because they shouldn't last long. If HEAP_XMIN_INVALID or
> >> HEAP_XMAX_COMMITTED is set, then it's (hopefully) going to be vacuumed
> >> soon, and gone completely. And if HEAP_XMAX_INVALID is set, then it
> >> should just be changed to InvalidTransactionId.
> >
> > Hm.  It is not cheaper to change xmax to 0 than it is to set the hint
> > bit --- you still need a write, and there are also added locking and
> > atomicity worries --- so I'm not convinced by your argument there.
> > But you might be right that the expected number of wins from the other
> > two bits is a lot less.
>
> Is that true in a post checksum world though? Given that we are
> logging changes can we relax atomicity expectations?  IIRC xmin/xmax
> are aligned, how come you can't just set InvalidTransactionId for
> INVALID and 'FrozenTransactionId' for COMMITTED?   Why can't you do
> this now?

Uhm. The latter doesn't really work if you have any transactions that
might not see that row or am I missing something?

Greetings,

Andres Freund


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-11-16 14:59:35
Subject: Re: another idea for changing global configuration settings from SQL
Previous:From: Euler TaveiraDate: 2012-11-16 14:57:14
Subject: Re: another idea for changing global configuration settings from SQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group