Index scan ordering (performance)

Hi all,

I'm looking at ways to improve PG performance where index scans are
concerned. The layout of our database and our access habits really hit PG's
index code square in the chops. Many of our queries spend way too much time
waiting for disk seeks, and I believe this is fully caused by the way PG
does index scans.

In the TODO list is an entry "Order duplicate index entries by tid for
faster heap lookups". I think this change would prove *very* beneficial for
us. Is anybody working on this? Is it considered important by many people?

Ordering duplicate index entries would obviously help for... uh...
duplicate entries, but what about non-duplicates being accessed in a range
scan? If the executer were to handle the ordering at read time, it would
work for ranges as well. Would it be wildly difficult to have the executer
scan more than one index entry before doing the related heap accesses? That
way you could read X number of index entries (or all of them), order the
resulting list on tid, and then go after the heap. It seems that the only
side effect from this would be tid-ordered default sorting rather than
index-ordered default sorting (which does not effect SQL compliance).

Any ideas what status is on this stuff? Should I dive in and try to do it
myself?

Glen Parker
glenebob(at)nwlink(dot)com