Re: Traffic jams in fn_extra

From: Greg Stark <stark(at)mit(dot)edu>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Traffic jams in fn_extra
Date: 2013-11-27 13:44:07
Message-ID: CAM-w4HMYmx=1TwbdPR7No8yCvjFurGOyN+GRDF5j9yGX00cEOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 24, 2013 at 4:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> Why do you need to do this dance with fn_extra?
>
> It's possible to allocate a hash table in a Transaction-lifetime
> memory context on first call into a function then cache things there.
>

fn_extra gives a handle per function call site.

It sounds to me like the complexity is coming not from having many Postgres
functions but from having lots of infrastructure backing up those
functions. So if many of their Postgres functions call a C function to do
various things and the C function wants to cache something somewhere
related to the object they've been passed then the natural thing to do is
have the Postgres function pass fn_extra down to the C function but if they
have many such C functions it gets a bit tricky.

But you could declare fn_extra to be a hash table yourself since it's your
Postgres function that gets to decide how fn_extra is going to be used. You
could then pass that hash table down to the various C functions to cache
state. However that might still be a bit odd. If you call the same C
function twice from the same Postgres function it'll get the same hash
table for both calls. fn_extra is per Postgres function call site.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-11-27 13:47:10 Re: Handling GIN incomplete splits
Previous Message Alvaro Herrera 2013-11-27 13:29:34 Re: Status of FDW pushdowns