[postgis-users] Help with Bad Query Plan

[Mark Cave-Ayland]

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


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063