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

[Nicklas Avén]

Great!

The special treatment for 2D (with fixed length key) is very important I
think and worth the double indexes since all panning, zooming and so on
in any gis system relies on that (if it is not caching the geometries,
but that is not very common, is it?)

Sacrifying that performance for cleaner more nice looking sql interface
would be bad I think.

(If I have understood things right)

/Nicklas

On Fri, 2011-03-18 at 08:51 -0400, Paul Ramsey wrote:
> It's solved, as far as I can tell.
> First, if you're just flat testing with trunk vs 1.5 you'll see no
> difference because the new serialization/index isn't turned on unless
> you set GSERIALIZED on in the postgis/gserialized.h file.
> Second, with the fixed length key the new implementation is as fast as
> the old one now. With the variable length key it was not.
> P.
> 
> On Fri, Mar 18, 2011 at 8:32 AM, Nicklas Avén
> <nicklas.aven at jordogskog.no> wrote:
> > 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
> >>
> >
> >
> > _______________________________________________
> > 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
>