Re: Performance (was: The New Slashdot Setup (includes MySql server))
От | Tom Lane |
---|---|
Тема | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
Дата | |
Msg-id | 8450.958754357@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance (was: The New Slashdot Setup (includes MySql server)) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Performance (was: The New Slashdot Setup (includes MySql
server))
Re: Performance (was: The New Slashdot Setup (includes MySql server)) RE: Performance (was: The New Slashdot Setup (includes MySql server)) |
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: