[postgis-devel] Recheck Considered Harmful (or, at least, Slow)

Paul Ramsey pramsey at cleverelephant.ca
Sat Oct 11 17:34:34 PDT 2008


On Sat, Oct 11, 2008 at 4:29 PM, David Fuhry <dfuhry at acm.org> wrote:

>   My understanding of exact GIST behavior here is fuzzy.  I don't quite
> understand what geometries would be rejected only by the
> LWGEOM_gist_consistent() RECHECK, given that the bbox extracted from the
> geometry is of type float (BOX2DFLOAT4), not double precision.  Won't the
> extracted getbox2d_p bbox match exactly the bbox from the index?

Actually, yeah, that seems reasonable...  The SRID check is in the
actual strategy calls, and, curiously, since the overlap strategy has
been inlined, I guess that means we do an SRID check only for ops that
aren't && (huh?). And yes, the bbox checks just seem to be extracting
the box from the geometry and checking it against the index box.

I guess the deeper question is: what does is this consistent call
(LWGEOM_gist_consistent) meant to achieve, and are we achieving
anything? Can we just return TRUE and be done w/ it?

>   Without RECHECK, could current behavior be preserved by adding an "AND
> ST_Intersects(...)" to the query?  If so, that would be a simple
> justification for the change.  I'm using 8.3 without RECHECK but I didn't
> realize it skipped anything beyond the SRID equality check.
>
>   In the worst case, pg_detoast_datum_slice would have to grab only the
> first VARHDRSZ + sizeof(flags) + sizeof(SRID) + sizeof(BOX2DFLOAT4) bytes,
> is that right?  It seems there's no downside.

Yes, it seems like it would certainly be better. However, I'd like to
aim for "best". If we don't need all this scruft, I'd like to drop it.

P.



More information about the postgis-devel mailing list