On Thu, Feb 25, 2010 at 3:16 AM, Gokulakannan Somasundaram
<gokul007@gmail.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.
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.
