Thanks, It does look like an incorrect prediction. Looking again, I think it's the row estimate for the join that's out - the planner estimates 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 from the query plan where there is a slow query and automatically test turning off nested joins. I'll just have to keep an eye 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@xxxxxxxxxx>: >> b2deliveryorders.complete = false AND b2deliveryorders.invoiced = false -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
