[postgis-devel] ST_OrderingEquals vs ~=

Kevin Neufeld kneufeld at refractions.net
Sat Jun 20 19:08:12 PDT 2009


Actually, looking at it, I think this is correct. 

~= does not use indexes.  The operator invokes 'ST_geometry_same' which 
exposes the C function
'LWGEOM_same' found in 'lwgeom_functions_basic.c'.

Your other comment about ST_Equals could be looked at however. 
It currently just calls geomequals, without making use of any indexes.  
Shouldn't the function be a simply wrapper for 'SELECT $1 & $2 AND 
_ST_Equals($1, $2)'?

Also, why is the = operator bound to lwgeom_eq and not LWGEOM_same?  The 
former uses bounding boxes for comparison and the later compares exact 
geometry equality.  I know that this operator is used in GROUP BY 
expressions .. but would it be beneficial to GROUP BY the exact 
geometries instead of just their bounding boxes? This is such a big 
PostGIS gotcha.

Anywho, just some thoughts.
-- Kevin

Paragon Corporation wrote:
> I think Kevin mentioned this before and he wasn't sure why either but
> thought I would bring it up since I'm not clear what the reason for this is.
>
> Our ST_OrderingEquals function is a short-hand for 
> SELECT $1 && $2 AND $1 ~= $2
>
> But ~= already uses a GIST index doesn't it?  So why this extra $1 && $2
> check?
>
> Is the && faster to compute? Or have higher selectivity?
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   



More information about the postgis-devel mailing list