Re: explain analyse and nested loop joins - Mailing list pgsql-general

From Oliver Kohll - Mailing Lists
Subject Re: explain analyse and nested loop joins
Date
Msg-id 5B34B39C-85BF-4D33-8BC4-3D29ADB8A485@gtwm.co.uk
Whole thread Raw
In response to explain analyse and nested loop joins  (Oliver Kohll - Mailing Lists <oliver.lists@gtwm.co.uk>)
List 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 by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Linker error VS2008 c++
Next
From: Merlin Moncure
Date:
Subject: Re: PostgreSQL references in the Middle East