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

[Martin Davis]

So the conclusion is that using the simple form is probably good enough 
for reasonable cases?

Did you test this performance against the original ST_Contains, so we 
can get a baseline to compare to?

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
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022