Re: Traffic jams in fn_extra

On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
>> 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
>
> TBH, I fail to understand what you're on about here. Any one function
> owns the value of fn_extra in calls to it, and is solely responsible for
> its usage; furthermore, there's no way for any other code to mangle that
> pointer unless the owner explicitly makes it available. So where is
> the problem? And if there is a problem, how does adding another field
> of exactly the same kind make it better?

Right, sorry, I'm reasoning overly aggressively from the specific to
the general. The specific problems have been

- two lines of geometry caching code, either of which can be called
within a single function, depending on the inputs, which mostly didn't
result in conflicts, except when they did, which was eventually
rectified by layering a GenericCacheCollection into the function
- a cached lidar schema object which would have been very useful to
have around in an SRF, but couldn't because the SRF needed the
fn_extra slot

The first case is an application-specific problem, and since we've
coded around it, the only advantage to a pgsql-specific fix would be
to allow others who also need to cache several independent things to
not reinvent that wheel.

The second case is one of the instances where the pgsql code itself is
getting in the way and cannot be worked around at the application
level. My solution was just not to do caching for that function.

So, that's what I perceive the problem to be. Now that you point it
out to me, yes, it's pretty small bore stuff.

On the solution, I wasn't suggesting another void* slot, but rather a
slot that holds a hash table, so that an arbitrary number of things
can be stuffed in. Overkill, really, since in 99.9% of times only one
thing would be in there, and in the other 0.1% of times two things. In
our own GenericCacheCollection, we just statically allocate 16 slots.

P.