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

> I've noticed the fact since before but haven't complained.
> As far as I see,pg_index won't so big. In fact Matthias's case has
> only 1 page after running vacuum for pg_index. In such cases
> sequential scan is faster than index scan as you know.
> I don't agree with you to increase system indexes easily.
> Though I implemented REINDEX command to recover system
> indexes it doesn't mean index corruption is welcome.
>
> I know another case. pg_attrdef has no index on (adrelid,attnum)
> though it has an index on (adrelid).
>
> > More generally, someone should examine the other places where
> > heap_getnext() loops occur, and see if any of them look like performance
> > bottlenecks...
>
> Please don't lose sequential scan stuff even when changes to
> index scan is needed because -P option of standalone postgres
> needs sequential scan for system tables.

Certainly whatever we do will be discussed. I realize initdb is an
issue. However, I am not sure sequential scan is faster than index scan
for finding only a few rows in the table.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026