[postgis-devel] What's the point of this exercise in intersects?

[Mark Leslie]

Obe, Regina wrote:
>
> >> It gets better, since the bbox check often recurs in the GEOS code
> >> base too. However, it's not exactly a high cost check, and there are
> >> cases where there functions will be called sans indexes. Doing the
> >> check in postgis potentially saves a trip to GEOS. The GEOS checks
> >> have to be there to support pure-GEOS apps.
>
> >> C'est la vie.
>
> >> P.
>
> Paul,
>
> I wish I could be so accepting of lifeas you. Perhaps life would be
> much easier for me to bear.
>
> The GEOS bbox extra check I whole-heartedly accept as the price of
> sharing code.  The
> PostGIS one though - it seems even if other projects were sharing
> PostGIS code, these functions
> are so tied to PostgreSQL  that they would be taking advantage of the
> same treats we are and cursory inspecting the code base
> couldn't find a situation where this would be called sans indexes
> except by newbies (maybe I didn't inspect enough). 
>
> So which places do you see where you would ever call this function and
> not have already done a bounding box check already?
>
There are cases where the geometry is generated within the query, such
as by buffering and the like, where an index cannot be created.  There
are cases where a sequence scan is selected by the scheduler for
whatever reason (selectivity of other constraints, size of table,
outdated stats...).  And there's the case where the user didn't build an
index.  Given the low overhead these shortcuts introduce, I would prefer
to leave them in order to cover these sorts of cases.

--
Mark Leslie