Re: 7.2.1 optimises very badly against 7.2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 7.2.1 optimises very badly against 7.2
Дата
Msg-id 16800.1026309638@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 7.2.1 optimises very badly against 7.2  ("Sam Liddicott" <sam.liddicott@ananova.com>)
Ответы Re: 7.2.1 optimises very badly against 7.2  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
"Sam Liddicott" <sam.liddicott@ananova.com> writes:
> But I feel where indexes are used and seq_scan *could* have been used,
> seq_scan is only slightly faster where the machine is idle (and the small
> delay can perhaps be afforded), but where there there is disk head
> contention seq_scan is deadly, thus I always prefer index scan, so I shall
> disable seq_scan in the config file.  Is my reasoning faulty?

Quite.  If we could get by with a rule as simplistic as "never use a
seqscan if you can avoid it" then the planner could be a lot simpler.
Your real gripe is that the planner is overestimating the costs of
indexscans relative to seqscans; that would be more appropriately
addressed by lowering random_page_cost a little than by getting out
the sledgehammer.

A more practical reason not to do that is that in situations where a
seqscan is not avoidable, enable_seq_scan = OFF is likely to cause the
planner to make bad choices, since the disable cost will swamp out all
the actually-useful cost judgments.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: I am being interviewed by OReilly
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Date/time precision in 7.2