Re: Very specialised query

Поиск
Список
Период
Сортировка
От Віталій Тимчишин
Тема Re: Very specialised query
Дата
Msg-id 331e40660903301113x7371fb33n302fc3f2c720efb2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Very specialised query  (Matthew Wakeling <matthew@flymine.org>)
Ответы Re: Very specialised query
Список pgsql-performance

Yeah, that's nice.

However, it is still the case that we can't trust the database to choose the correct plan. It is currently only choosing the correct plan now by chance, and some time later it may by chance switch to one that takes 40 minutes.

What is the bad plan? Is it like the first plan from your first message?
You can sometimes tweak optimizer to make sure it will do correct plan. E.g. when your database fits in memory, you can tweak page access costs. Also don't forget to raise statistics target.

BTW: About aggregates: they can return arrays, but I can't imagine what you can group by on... May be windowing functions from 8.4 could help.

Also, if your maximum length (select max(end-start) from location) is low enough, you can try adding some more constraints to make optimizer happy (have it more precise row count to select correct plan).

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

Предыдущее
От: dan@sidhe.org
Дата:
Сообщение: Trying to track down weird query stalls
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Trying to track down weird query stalls