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
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
