Re: explain analyse and nested loop joins

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