[postgis-devel] Common Code

[Chris Hodgson]

Let me just make sure I/we understand this correctly. We already have 
code for caching:

- 1-D r-tree indexes of lwgeoms
- prepared geoms aka. geos geoms
- Proj contexts

All of these caches store at most the two most recently created 
indexes/geoms/contexts. As I understand it there a few problems:

- the prepared geom and r-tree indexes overwrite each other which leaks 
big memory for some queries (Trac #547)
- looking at the proj4 cache code, it appears that it would also 
overwrite/be overwritten by the prepared geom and r-tree index caches 
(all appear to use fcinfo->flinfo->fn_extra as if no-one else was using it)
- we have three different but similar implementations of caching 
(duplicate code and maintenance effort)
- none of these implementations are located where we really want them to 
be, given that the proj caching is needed by the raster libraries (Tracs 
#1053, #1133, #1058, and friends) and that the r-tree and prepared geoms 
might be more useful in liblwgeom, or at least outside of the 
postgres-dependent postgis package.

Bryce has proposed (and provided a patch for) moving the proj caching 
into a new libcommon.

Strk would like to see libcommon named something with PG in its name and 
I agree except that PG is not distinct from "PostGIS" so perhaps it 
needs the entire "postgres" in it's name. postgres_common or pgcommon I 
guess could work.

Mark has suggested that we take it a step or two further:

- extract the proj caching into a non-postgres dependent part and put 
that in liblwgeom, while leaving the postgres dependent part in libcommon
- do the same thing with the r-tree and prepared geom caching, ideally 
consolidating the caching support so that it correctly supports caching 
all of our current things and could easily be extended to cache other 
things in the future

After reviewing the amount of code involved in all of those caching 
functions, I guess I'm not entirely against a BDB key-value store based 
implementation, although I can't help but think our situation is limited 
in some ways (very few keys/values being stored, simple keys) that makes 
the generic BDB implementation a bit overkill.

We really should fix the caching so that they don't overwrite each 
other, that bug has been around a long time ... however apparently we 
don't exercise that code path much because there aren't too many 
complaints about it. All the more reason for making them more easily 
testable as per Mark's suggestion.

Hopefully strk's lwgeom work aligns well with Mark's plan?

Sorry I don't have much to contribute here myself, I just felt like I 
needed a summary after we've seen parts of this conversation spread over 
dozens of e-mails and tracs.

Chris

Bryce L Nordgren wrote:
>
> It's simple enough if to write custom caching code for each data type 
> you want to cache. But if you want polymorphism, you want a language 
> other than C. Implementation of a polymorphic design in a language 
> which does not support polymorphism is going to be anything but 
> simple, and will probably end up looking similar to this:
>
> http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_main.html
>
> I was not able to quickly locate alternative C implementations of 
> "Map"/"Dictionary" in library form.
>
> Bryce
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>