[postgis-devel] Re: [postgis-users] GIST index speed

[Markus Schaber]

Hi, Tom,

Tom Lane <tgl at sss.pgh.pa.us> wrote:

> Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> writes:
> > Okay. The reason I was thinking about Datum was because I was thinking 
> > about trying to cache the results of the PostGIS -> GEOS transformation 
> > for non-TOASTed as well as TOASTed objects. So effectively we'd need to 
> > keep both the PostgreSQL geometry type and the GEOS-converted PostgreSQL 
> > geometry type around where we can access them. With your suggestion, I'm 
> > guessing that we would only be able to cache the PostGIS -> GEOS 
> > transformation for TOASTed objects. Maybe that would be enough, although 
> > it's one of those things that would be difficult to test without an 
> > actual implementation :(
> 
> Yeah.  I don't really see any way to cache stuff for datums that aren't
> toasted out-of-line, because there's no unique identifier assigned to
> them that you could use for a cache lookup key.  On the other hand,
> if the geometry isn't big enough to get toasted, it can't be all that
> expensive to convert, so maybe such a solution is Good Enough.

For this solution, we need a custom "cleanup" callback, as PostgreSQL
does have no way how to clean up the GEOS transformed geometry.

But I had another idea this morning. 

Mark, does GEOS have custom coordinate sequences like JTS? Then you
simply could construct a geometry wrapper that does not copy the
coordinates, but references the detoasted data "in place". That should
work at least on those platforms which support non-aligned accesses.


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org