Re: index / sequential scan problem
От | Paul Thomas |
---|---|
Тема | Re: index / sequential scan problem |
Дата | |
Msg-id | 20030717153825.C27991@bacon обсуждение исходный текст |
Ответ на | Re: index / sequential scan problem (Fabian Kreitner <fabian.kreitner@ainea-ag.de>) |
Ответы |
Re: index / sequential scan problem
|
Список | pgsql-performance |
On 17/07/2003 13:50 Fabian Kreitner wrote: > [snip] > Im afraid, no. > Database has been stopped / started right before this. > [snip] 1) enable_seqscan = true > Seq Scan on notiz_objekt a (cost=0.00..56125.80 rows=15561 width=12) > (actual time=0.28..2298.71 rows=31122 loops=1) > [snip] 2) enable_seqscan = false > Seq Scan on notiz_objekt a (cost=100000000.00..100111719.36 rows=15561 > width=12) (actual time=0.25..535.75 rows=31122 loops=1) I've just noticed this. Something is not right here. Look at the crazy cost estimation for the second query. It looks to me like enable_indexscan, enable_tidscan, enable_sort, enable_nestloop, enable_mergejoin or enable_hashjoin have been set to false. Looking at the source, thats the only way I can see that such large numbers can be produced. HTH -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+
В списке pgsql-performance по дате отправления: