Greg Stark <gsst...@mit.edu> writes: > In indexes we currently get away with a reduced header which has few > of the 6 bytes of info bits. However the only reason we can do is > because we impose arbitrary limitations that work for indexes but > wouldn't be reasonable for tables. Such as a lower maximum number of > columns, inability to add new columns or drop columns later, etc.
Wait a second, which idea are we currently talking about? No heap at all, or just the ability to check visibility without visiting the heap? If it's a genuine IOT (ie no separate heap), then you are not going to be able to get away without a full heap tuple header. We've sweated blood to get that struct down to where it is; there's no way to make it smaller without giving up some really fundamental things, for example the ability to do UPDATE :-( If you just want to avoid a heap visit for visibility checks, I think you'd only need to add xmin/xmax/cmin plus the hint bits for same. This is going to end up costing 16 bytes in practice --- you might think you could squeeze into 12 but on 64-bit machines (MAXALIGN 8) you'll save nothing. So that's effectively a doubling of index size for common cases such as a single int4 or int8 index column. The other problem is the extra write load created by needing to update the index's copies of the hint bits; not to mention extra writes to freeze the xids when they get old enough. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers