Re: Performance (was: The New Slashdot Setup (includes MySql server))

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> The advantage is that you can then index a bunch more of the system
>> catalog tables, and on a bunch more attributes. That produced some
>> surprising speedups.

> We have indexes on all system tables that need it.

There isn't any fundamental reason why the planner can't be using an
index to scan pg_index; we just need to code it that way. Right now
it's coded as a sequential scan.

Unfortunately there is no index on pg_index's indrelid column in 7.0,
so this is not fixable without an initdb. TODO item for 7.1, I guess.

More generally, someone should examine the other places where
heap_getnext() loops occur, and see if any of them look like performance
bottlenecks...

regards, tom lane