API for optimized predicates (was Re: [postgis-devel] 1.3.3)

[Chris Hodgson]

Again, I have to ask, how big are your polygons? That 5% number should 
vary significantly based on the size of your polygons, from a few points 
up to a few thousand points.

Chris

Paul Ramsey wrote:
> Nice catch.
> 
> Without STRICT, the ST_Contains(g,g,null) case returns about 5% slower
> than the id-tested case from my unpatched copy of postgis.  The
> id-tested case in the patched copy blows up, which is odd, since I
> can't see any real changes in that case from the original.
> 
> P.
> 
> On Wed, Apr 2, 2008 at 3:56 PM, Mark Leslie <mark.leslie at lisasoft.com> wrote:
>> Mark Leslie wrote:
>>
>>> ST_Contains(geometry, geometry, integer) is defined as 'isstrict'.  This
>> is a PostgreSQL optimization that will cause the function to return null
>> anytime any argument is null.
>>> I'm sure it's screaming fast though.
>>>
>>>
>>  Sorry, I didn't get that quite right.  ST_Contains is not strict, but it
>> calls _ST_ContainsPrepared which is.
>>
>>
>>  --
>>  Mark Leslie
>>  Geospatial Software Architect
>>  LISAsoft Pty Ltd
>>  +61 (0)2 8570 5050
>>
>>  Commercial Support for Geospatial Open Source Software
>>  http://www.lisasoft.com/LISAsoft/SupportedProducts.html
>>
>>
>>  _______________________________________________
>>  postgis-devel mailing list
>>  postgis-devel at postgis.refractions.net
>>  http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel