Re: A thought on Index Organized Tables

If it's of any interest, I can say something about the hint bits in the index tuple header. In my implementation, my
decisionwas 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<br /><br />(xmin is committed OR xmin = InvalidTransactionId)<br />AND (xmax is committed OR xmax =
InvalidTransactionId)<br/><br />Then there are 12 bytes for xmin/xmax/cid. I did sweat something over this decision...
butmaybe it was a wasted effort if the 12 bytes end up occupying 16 bytes anyway.<br /><br />Karl<br /><br /><div
class="gmail_quote">OnThu, Feb 25, 2010 at 1:25 PM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Greg
Stark<<a href="mailto:gsstark@mit.edu">gsstark@mit.edu</a>> writes:<br /> > In indexes we currently get away
witha reduced header which has few<br /> > of the 6 bytes of info bits. However the only reason we can do is<br />
>because we impose arbitrary limitations that work for indexes but<br /> > wouldn't be reasonable for tables.
Suchas a lower maximum number of<br /> > columns, inability to add new columns or drop columns later, etc.<br /><br
/></div>Waita second, which idea are we currently talking about?  No heap at<br /> all, or just the ability to check
visibilitywithout visiting the heap?<br /><br /> If it's a genuine IOT (ie no separate heap), then you are not going
to<br/> be able to get away without a full heap tuple header.  We've sweated<br /> blood to get that struct down to
whereit is; there's no way to make it<br /> smaller without giving up some really fundamental things, for example<br />
theability to do UPDATE :-(<br /><br /> If you just want to avoid a heap visit for visibility checks, I think<br />
you'donly need to add xmin/xmax/cmin plus the hint bits for same.<br /> This is going to end up costing 16 bytes in
practice--- you might<br /> think you could squeeze into 12 but on 64-bit machines (MAXALIGN 8)<br /> you'll save
nothing. So that's effectively a doubling of index size<br /> for common cases such as a single int4 or int8 index
column. The other<br /> problem is the extra write load created by needing to update the index's<br /> copies of the
hintbits; not to mention extra writes to freeze the xids<br /> when they get old enough.<br /><br />                  
    regards, tom lane<br /></blockquote></div><br />