Re: Look at heap_beginscan()
От | Tom Lane |
---|---|
Тема | Re: Look at heap_beginscan() |
Дата | |
Msg-id | 2665.960363196@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Look at heap_beginscan() (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Look at heap_beginscan()
|
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Just do a search for heap_beginscan() and look at all those system table > heap scans. Clearly, for large installations, we should be doing index > scans. There are a bunch of heap_beginscan() calls, but my first impression from a quick scan is that most of them are in very non-performance- critical paths --- not to mention paths that are deliberately ignoring indexes because they're bootstrap or reindex code. Furthermore, some of the remainder are scans of pretty darn small tables. (Do we need to convert sequential scans of pg_am to indexed scans? Nyet.) I'd be real hesitant to do a wholesale conversion, and even more hesitant to add new system indexes to support indexscans that we have not *proven* to be performance bottlenecks. It's certainly something worth looking at, since we've identified a couple of places like this that are indeed hotspots. But we need to convince ourselves that other places are also hotspots before we add overhead in hopes of making those places faster. regards, tom lane
В списке pgsql-hackers по дате отправления: