[postgis-users] Help with Bad Query Plan
mark.cave-ayland at siriusit.co.uk
Fri Jan 9 05:14:31 PST 2009
Obe, Regina wrote:
> Slight correction. I don't believe this statement to be true.
> && from all my experience in 8.3 still evaluates first before
> _ST_Intersects. Where you get bitten is
> that _ST_Intersects sometimes evaluates before other things.
> I think like if you had something like
> WHERE ST_Intersects(...) AND somedate between a and b
> Then in 8.2 if you had an index on somedate, ST_Intersects would run
> second regardless of the order of your
> conditions. In 8.3 if you put ST_Intersects first because we didn't
> define a costing for ST_Intersects -- it often evaluates first.
> which would be bad since an indexed somedate would be a better choice to
> check first.
Right, thanks for the clarification - I'd obviously misunderstood the
original report. I'm tempted to add the 8.3+ function costings to the
1.4 TODO list as I can see this biting more people...
If this is the case, it seems Oliver is almost certainly being bitten by
the && operator RECHECK :(
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063
More information about the postgis-users