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

[Mark Leslie]

Obe, Regina wrote:
> Mark,
>   
>>  Why can't you be happy with bliss?
>>     
> I feel a little bit more blissful now.  Thanks Mark.
>
> Eternal Bliss is so boring.  Life is about misery and overcoming it or
> making yourself more miserable.  It is all about having non-zero
> derivatives :)
>
>   
>>  As for the generated geometries, they are automatically generated in
>>     
> a
>   
>> number of cases, which are documented somewhere in the code.  I don't
>> recall what they all were were, but they included such vague cases as,
>> 'sufficiently complex geometries,' as well as some quite specific
>>     
> ones,
>   
>> such as 'never on points'.
>>     
>
> Hmm so in these cases I presume this redundancy may be useful?  Although
> in these cases do 
> we make sure to add a bbox to the geometry.  Looking at the comment of
> the code - it seems to suggest
> the BBOX short-circuit would happen only if there already existed a bbox
> attached to the geometry, but I am
> not sufficiently skilled in my C reading to determine if the code
> completely matches the comment and whether these  generated geometries
> you refer to have bboxes.
>
> I'm still questioning how cheap of a call this is though - looks
> harmless but you never know.  
>
> Maybe I'll do some large data runs of point in Polys with and without to
> see how much of a difference it makes. 
>
> If it were an index call, it would be cheap for sure, but
> its not, so I can only assume its worse or at best as good as doing a
> non-indexed && on a set of geometries you know will already return true.
>   
That's not quite true for all cases.  If bboxes exist, it should be the
same performance per pair as the non-indexed &&, but it will be run on
fewer pairs when it's redundant, and will improved performance
considerably when it's not.  There's also the question of what the &&
operator compares when there are no bboxes.  My assumption, which I'm
open to having corrected, is that it will create bboxes for the purpose
of comparison, but will not write it into the geometry.  If this is in
fact the case, the non-indexed && would be terribly slow indeed, while
the short-circuit itself would be short-circuited.

Doing some quick (and questionable) math in my head, it seems like the
short-circuit would perform up to four floating point comparisons, two
32 bit copies, and a dozen or so branches.  I'm not sure the cost of
casts and such.  Seems reasonably expensive, until you consider the cost
of an actual comparator.

Really, it's the tests that will determine it's value.  I may run a few
of my own today and see what I get.

-- 
Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com