From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Karl Schnaitter <karlsch(at)gmail(dot)com> |
Cc: | pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A thought on Index Organized Tables |
Date: | 2010-02-26 00:14:30 |
Message-ID: | 9671.1267143270@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-02-26 00:16:15 | Re: trouble with to_char('L') |
Previous Message | Karl Schnaitter | 2010-02-26 00:11:54 | Re: A thought on Index Organized Tables |