Re: A thought on Index Organized Tables

On Thu, Feb 25, 2010 at 3:16 AM, Gokulakannan Somasundaram <
gokul007(at)gmail(dot)com> wrote:

>
> I haven't thought about whether this is sufficient but if it is then
>> an initial useful thing to add would be to use it for queries where we
>> have a qual that can be checked using the index key even though we
>> can't do a range scan. For example if you have a btree index on
>> <a,b,c> and you have a WHERE clause like "WHERE c=0"
>>
>> That would be a much smaller change than IOT but it would still be a
>> pretty big project. Usually the hardest part is actually putting the
>> logic in the planner to determine whether it's advantageous. I would
>> suggest waiting until after 9.0 is out the door to make sure you have
>> the attention of Heikki or Tom or someone else who can spend the time
>> to check that it will actually work before putting lots of work coding
>> it.
>>
>> I will try that. Thanks ...
>

Some more ideas popped up. I am just recording those.
a) In place of block id( this has to be issued for every new/recycled block
and it is not there in postgres), we can even have SnapshotNow's transaction
id. I just feel the synchronization effect will be more here.
b) We can just record the currentTimestamp in the page. While this is
without any synch, it might create problems, when we decide to go for
Master-Master replication and Distributed databases. So when such things
happens, the clock on the various systems have to be synched.

Gokul.