Traffic jams in fn_extra

As an extension with a lot of CPU load, we (postgis) tend to use flinfo->fn_extra a lot, for caching things that are intensive to calculate at the start of a query and reuse throughout subsequent functions calls.

- coordinate projection objects
- indexes of the edges of large geometries
- other kinds of indexes of the edges of large geometries :)
- schemas of lidar pointcloud collections

As we've added different kinds of caching, in our own project, we've banged up against problems of multiple functions trying to stuff information into the same pointer, and ended up putting an extra container of our own into fn_extra, to hold the different kinds of stuff we might want to store, a GenericCacheCollection

https://github.com/postgis/postgis/blob/svn-trunk/libpgcommon/lwgeom_cache.c#L46-L48

As (by now) a connoisseur of fn_extra caching, I've noticed while reading bits of PgSQL code that there are far more places that stuff state into fn_extra than I ever knew, and that they do so without any substantial concern that other state might already be there. (Well, that's not true, they usually check for NULL and they give up if fn_extra is already in use.) The range types, I was surprised to find doing some performance caching in fn_extra. The set-returning function macros use it to hold state. And many others I'm sure.

Would it be good/wise to add another, better managed, slot to flinfo, one that isn't just void* but is a hash? (Or, has some management macros to handle it and make it a hash* if it's null, whatever API makes sense) so that multiple bits of code can cache state over function calls without banging into one another?

flinfo->fn_extra_hash perhaps?

If this sounds OK, I'd be honored to try and make it my first submission to PgSQL.

P.

--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net