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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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