Karl Schnaitter <karlsch(at)gmail(dot)com> writes:
> If it's of any interest, I can say something about the hint bits in the
> index tuple header. In my implementation, my decision was to use only one
> hint bit. It went into the unused 13th bit of the IndexTuple header. When
> the hint bit is set, it means that
> (xmin is committed OR xmin = InvalidTransactionId)
> AND (xmax is committed OR xmax = InvalidTransactionId)
> Then there are 12 bytes for xmin/xmax/cid. I did sweat something over this
> decision... but maybe it was a wasted effort if the 12 bytes end up
> occupying 16 bytes anyway.
Actually, if you need to squeeze a few more bits into that word, the
thing to do would be to get rid of storing the tuple length there.
This would involve adding the same type of indirection header that
we use for HeapTuples, so that the length would be available at need
without going back to the item pointer. It'd be an invasive code change
but reasonably straightforward, and then you'd have room for normal hint
bits. Squeezing cmin in there is just fantasy though.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2010-02-26 00:16:15|
|Subject: Re: trouble with to_char('L')|
|Previous:||From: Karl Schnaitter||Date: 2010-02-26 00:11:54|
|Subject: Re: A thought on Index Organized Tables|