Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Дата
Msg-id 603c8f071002101231k45e9161eyeacf9072219489eb@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  (Bryce Nesbitt <bryce2@obviously.com>)
Ответы Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  ("Jorge Montero" <jorge_montero@homedecorators.com>)
Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  (Bryce Nesbitt <bryce2@obviously.com>)
Список pgsql-performance
On Wed, Feb 10, 2010 at 3:29 AM, Bryce Nesbitt <bryce2@obviously.com> wrote:
> Or, if you want to actually read that query plan, try:
> http://explain.depesz.com/s/qYq

Much better, though I prefer a text attachment...  anyhow, I think the
root of the problem may be that both of the subquery scans under the
append node are seeing hundreds of times more rows than they're
expecting, which is causing the planner to choose nested loops higher
up that it otherwise might have preferred to implement in some other
way.  I'm not quite sure why, though.

...Robert

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

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: Linux I/O tuning: CFQ vs. deadline
Следующее
От: rama
Дата:
Сообщение: perf problem with huge table