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>
Cc: Karl Schnaitter <karlsch(at)gmail(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-26 04:15:00
Message-ID: 9362e74e1002252015w471f900ft81175fc3a6302a43@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom,

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.  I


I feel the other one is easy. To store the hint bits inside the ItemId, in
the place of size. We have 16 bits there.Whenever the size is required, we
need to follow the offset and goto the corresponding tuple and then take the
size from there. The change seems to be minimal, but please bear with me, if
i am very ignorant about something.



>   Squeezing cmin in there is just fantasy though.
>

I think we can get away with this, by making the person, who inserts and
selects in the same transaction to go and find the visibility through heap.
In the Index tuple hint bits, we can note down, if the command is a simple
insert/update/delete. By Simple insert, i mean that it doesn't have a
select. So if that is the case, it can be made visible to statements within
the same transaction. We can even document, that people can just insert a
savepoint between their insert and select. This would increase the xid and
make that tuple visible within the same transaction. All that seems to be
possible.

Thanks,
Gokul.

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-26 04:15:29
Subject: Re: Allow vacuumdb to only analyze
Previous:From: Robert HaasDate: 2010-02-26 04:01:14
Subject: Re: Avoiding bad prepared-statement plans.

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