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

Re: A thought on Index Organized Tables

From: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, Karl Schnaitter <karlsch(at)gmail(dot)com>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-28 06:02:23
Message-ID: 9362e74e1002272202k3b88d9f8yeb9e1eaeab93116b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
If i have got over excited in the previous update, please ignore that.

a) We are already going from table to index to do unique checks. This is the
same thing, which we will do to go and update the snapshot in the indexes.
b) The way, it should work would be to have a check on whether the operator
is broken / function is volatile and put the onus on the user to make sure
that they are updated correctly.
c) In the ItemId, instead of removing the size field completely, we can
store the size as size/4(since it is MaxAligned). This will save us 2 bits.
In index we only need 13 bits to store the complete size in the tuple, but
we use 15 bits in the iid, so again we can have two more bit savings there.
That's sufficient for us to express the hint fields in a index. I think
Karl's way of expressing it requires only one bit, which looks very
efficient. So we can check the hint bits from the iid itself.

So just with a addition of 8 bytes per tuple, we can have the snapshot
stored with the index. Can someone please comment on this?

Thanks,
Gokul.

In response to

Responses

pgsql-hackers by date

Next:From: Mark KirkwoodDate: 2010-02-28 06:06:36
Subject: Re: Lock Wait Statistics (next commitfest)
Previous:From: Greg StarkDate: 2010-02-28 06:01:49
Subject: Re: Hot Standby query cancellation and Streaming Replication integration

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