[postgis-users] Help with Bad Query Plan

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Fri Jan 9 05:14:31 PST 2009

Obe, Regina wrote:

> Mark,
> 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 :(



Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063

More information about the postgis-users mailing list