Re: explain analyse and nested loop joins

Поиск
Список
Период
Сортировка
От Oliver Kohll - Mailing Lists
Тема Re: explain analyse and nested loop joins
Дата
Msg-id 5B34B39C-85BF-4D33-8BC4-3D29ADB8A485@gtwm.co.uk
обсуждение исходный текст
Ответ на explain analyse and nested loop joins  (Oliver Kohll - Mailing Lists <oliver.lists@gtwm.co.uk>)
Список pgsql-general
Thanks,

It does look like an incorrect prediction. Looking again, I think it's the row estimate for the join that's out - the
plannerestimates one row returned, in which case a nested join would probably make sense, whereas in fact there are 23. 

However it's a generated (user created) query, so I think what I might do is get the application to detect this case
fromthe query plan where there is a slow query and automatically test turning off nested joins. I'll just have to keep
aneye on it to see if it becomes unnecessary in future PG versions. 

Regards
Oliver
www.agilebase.co.uk

On 6 Nov 2011, at 04:17, Pavel Stehule wrote:

> Hello
>
> Propably there are a dependency between following columns - and then a
> prediction is not correct.
>
> Try to move one less selective to OUTER SELECT
>
> SELECT * FROM (SELECT your query OFFSET 0) x WHERE x.invoiced = false
>
> Regards
>
> Pavel Stehule
>
> 2011/11/5 Oliver Kohll - Mailing Lists <oliver.lists@gtwm.co.uk>:
>> b2deliveryorders.complete = false AND b2deliveryorders.invoiced = false


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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Linker error VS2008 c++
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: PostgreSQL references in the Middle East