> Bruce Momjian <pgman@candle.pha.pa.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.
The reason there is no index is because it is not a unique column, and
at the time I was adding system indexes for 7.0, I was looking for
indexes that could be used for system cache lookups. The index you are
describing returns multiple tuples, so it would be an actual index call
in the code. i will add this to the TODO.
>
> More generally, someone should examine the other places where
> heap_getnext() loops occur, and see if any of them look like performance
> bottlenecks...
Good idea. Added to TODO.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
