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

[Paul Ramsey]

A quick hack on LWGEOM_overlap to also use slicing takes the time for
my standard test case down further, from 4.9s to 3.7s.

So, to recap:

- old code, no prepare: 40s
- add prepared geom: 8s
- gist_consistent uses sliced detoast: 4.9s
- lwgeom_overlap uses sliced detoast: 3.7s

So, need to research a bit more into when bboxes are materialized, and
what cases would cause double de-toasting. I like your easy fix to the
point case, David.

P.

On Sun, Oct 12, 2008 at 3:44 PM, David Fuhry <dfuhry at acm.org> wrote:
> David Fuhry wrote:
>>
>> Paul Ramsey wrote:
>>>
>>> The only downside I can see is that, for very small objects and
>>> objects without bounding boxes (points) it is hard to avoid detoasting
>>> *twice*, once to see if the bbox is there, and a second time after the
>>> first attempt fails.
>>
>> For 2D points with no SRID, your PG_DETOAST_DATUM_SLICE call has already
>> pulled all of the data, right?  (VARHDRSZ + 1 + sizeof(BOX2DFLOAT4) ==
>> VARHDRSZ + 1 + sizeof(double) * 2)  If you have it pull four more bytes,
>> data retrieved by the _SLICE call can cover the 2D-point-with-SRID case,
>> too.
>
> Or actually no, _SLICEing four more bytes will cover all point cases, since
> a point's Z or M ordinates would not be used to determine _consistent-cy.
>
> So, no double DETOASTing for points in either case then.
>
> -Dave
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>