[postgis-devel] 3D Index / 2D Index concerns

[Nicklas Avén]

a side note

The performance problem with the new gist-index, or was it just the old
index on new serialisation.

Is the trunk now supposed to be slower than 1.5?
I did some testing the other day and had the same index speeds as 1.5.

It would be great with a ticket describing when the problem shows (if it
not already solved of course)

/Nicklas




On Fri, 2011-03-18 at 08:24 -0400, Paul Ramsey wrote:
> On Fri, Mar 18, 2011 at 8:12 AM, Paragon Corporation <lr at pcorp.us> wrote:
> > Paul,
> >
> >>> I guess that means in order to implement the && (2d interacts)  vs.
> >>> &&& (3d
> >>> interacts) --- you had have them share separate set of index creation
> >>> and operators?
> >
> >> They are actually two totally different indexes on the same serialization.
> > The 2D index builds based on a fixed-length key and the ND index builds
> > based on a variable-length key.
> > Not quite sure what the above means, but maybe I'll have a better idea if
> > you answer these questions:
> >
> > a) Do you have to explicitly specify you want a 2D/3D index during the build
> > process or does it go by the dimensionality of geometry?
> 
> To build a 2D index (the default)
> 
> create index geoindex on mytable using gist (geom);
> 
> To build an ND index (not the default)
> 
> create index geoindex on mytable using gist (geom gist_geometry_ops_nd);
> 
> (don't try the above, not currently implemented)
> 
> 
> > b) If it goes by the dimensionality of the geometry, what happens if you
> > have a table where the column is just geometry with no constraints etc.  Is
> > it a mix of both types?  Is that what you mean by they share the same
> > serialization?
> 
> In the ND case, the index is a mix and can handle multiple dimensionality.
> 
> > c) does 3D have an && and if so is it just an alias for &&&?
> 
> One operator can only have one definition for a particular type (it
> seems) so && will be ever and always only a 2D op for geometry.
> 
> > d) Is it possible to do a intersect check between a 2D geometry and 3D
> > geometry or because the indexes are built differently this is invalid?
> 
> The 2D index will continue to operate as currently, so basically 2.5D
> behavior (third/fourth dimensions exist but are ignored for indexing
> purposes)
> 
> The ND index behavior is not fleshed out yet, I have to walk the line
> between what I need the ops to do for good index building and what I'd
> like them to do for "rational" user facing behavior.
> 
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>