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: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>, Karl Schnaitter <karlsch(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-25 21:25:55
Message-ID: 15139.1267133155@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Erik RijkersDate: 2010-02-25 21:26:33
Subject: Re: Streaming replication and pg_xlogfile_name()
Previous:From: Greg StarkDate: 2010-02-25 21:08:26
Subject: Re: A thought on Index Organized Tables

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