[postgis-devel] Re: geometry stats

strk strk at keybit.net
Mon Mar 1 06:39:44 PST 2004


m.cave-ayland wrote:
> In summary I believe that the PostGIS index operators may be broken for
> non-point geometries. To solve this would not take much developer time
> at all and will nail these types of problems for once and for all. The
> plan should be something like:
> 
> 
> 1) Write our own equivalent of all the Rtree strategy bounding box
> checking routines, 
>    similar to what strk and I have done.

I've only rewritten the box_overlap() one.

> 2) Call the same function from the sequential operator and the index
> operator so they
>    both return the same geometries. This will prevent PostgreSQL from
> returning extra
>    geometries that will get discarded straight away by the next phase -
> no point in
>    making the DB do more work than it has to.

Sure! The sequencial operator would get the geometry's bvol, convert 
it to a BOX (or whatever datastructure used by the operators funx - see
below) and call the approriate method.

> 3) Add the RECHECK clause to the operator class; as per a discussion a
> while back between 
>    myself and Dave. This means that once the index tuples have been
> fetched, they will
>    also be passed through the sequential operator. This means that
> performing indexed
>    indexed queries should now throw an error if the query rectangle and
> the geometry have 
>    different SRIDs, instead of the current behaviour which is undefined.

This would make the query slower.
On the other hand if we make the index work on BOX_WITH_SRID objects
instead of just BOXes this could be made with the first scan. It
would make the index larger thought.

What about having the consistent function check for SRID match
looking at the table constraint ?  I know this is dirty, but
there might be a chance to have the SRID coded inside custom
data space associated with each table attribute (there was a discussion
in the pgsql-hackers mailing list about this - using geometry(<srid>)
as the datatype). A deeper integration would make this easier.

--strk;



More information about the postgis-devel mailing list