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

Re: A thought on Index Organized Tables

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-26 00:16:15
Subject: Re: trouble with to_char('L')
Previous:From: Karl SchnaitterDate: 2010-02-26 00:11:54
Subject: Re: A thought on Index Organized Tables

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