Re: proposal: be smarter about i/o patterns in index scan

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Tom Lane

> For starters, read the previous discussions of this in the archives.

Search doesn't work. Even if it did, I'm not sure what I would search on.
Do you remember the time frame of the discussion? If I could narrow it down
to a few months, I could possibly find it the slow way. I'd be very
interested to read it.

Anyway, this subject seems to get precious little attention, and I don't
understand why. PG's index scan implementation is so bad at some types of
queries, I find it surprising that there aren't weekly discussions about it,
and developers lined up around the block to work on it. I would be one of
those developers, but frankly the learning curve is pretty steep and I don't
have any smaller complaints to use as learning tools.

What am I missing? Why is a performance bottle neck of this magnitude not
on the same list of priorities as PITR, replication, and Win32?

> Two questions you should have answers to before starting to implement,
> rather than after, are how to deal with locking considerations and
> what will be the implications of giving up the property that indexscans
> deliver sorted output.

Here's one answer: If you had to sort every result set, even when an index
could have been used, overall performance would still improve by a very
large margin. I'd bet money on it.

Actually, the index would still have to be scanned in sort order. Only the
fetch order for heap tuples would be sorted differently.

Glen Parker