Re: Traffic jams in fn_extra

<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Sun, Nov 24, 2013 at 4:21 PM, Simon Riggs
<spandir="ltr"><<a href="mailto:simon@2ndquadrant.com" target="_blank">simon@2ndquadrant.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
id=":3tm"style="overflow:hidden">Why do you need to do this dance with fn_extra?<br /><br /> It's possible to allocate
ahash table in a Transaction-lifetime<br /> memory context on first call into a function then cache things
there.</div></blockquote></div><br/></div><div class="gmail_extra">fn_extra gives a handle per function call site.<br
/><br/>It sounds to me like the complexity is coming not from having many Postgres functions but from having lots of
infrastructurebacking up those functions. So if many of their Postgres functions call a C function to do various things
andthe C function wants to cache something somewhere related to the object they've been passed then the natural thing
todo is have the Postgres function pass fn_extra down to the C function but if they have many such C functions it gets
abit tricky.<br /><br /><br /></div><div class="gmail_extra">But you could declare fn_extra to be a hash table yourself
sinceit's your Postgres function that gets to decide how fn_extra is going to be used. You could then pass that hash
tabledown to the various C functions to cache state. However that might still be a bit odd. If you call the same C
functiontwice from the same Postgres function it'll get the same hash table for both calls. fn_extra is per Postgres
functioncall site.<br /><br clear="all" /><br />-- <br />greg<br /></div></div>