Re: Any advice about function caching? - Mailing list pgsql-hackers

From Mark Cave-Ayland
Subject Re: Any advice about function caching?
Date
Msg-id 9EB50F1A91413F4FA63019487FCD251D23931F@WEBBASEDDC.webbasedltd.local
Whole thread Raw
In response to Re: Any advice about function caching?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
> Sent: 07 November 2005 23:06
> To: Mark Cave-Ayland (External)
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Any advice about function caching?

(cut)

> If you want per-query state, keep it in a data structure 
> linked from the
> fcinfo->flinfo->fn_extra field (physically, store it in fn_mcxt, or 
> fcinfo->flinfo->create a subcontext of that if you wish).
> 
> If you need to get control at query shutdown to free 
> non-palloc'd resources, RegisterExprContextCallback may help. 
>  (I think such callbacks are only called during *successful* 
> query shutdown, though, so if you have external library state 
> you need to clean up anyway, you'll need some other approach 
> to keeping track of it ... maybe a permanent data structure 
> instead of a per-query one.)
> 
> src/backend/utils/fmgr/funcapi.c and 
> src/backend/executor/functions.c might be useful examples.


Hi Tom,

Thanks for the advice about state - this is definitely pointing me towards
looking at the existing code for aggregates and SRFs. Incidentally I've
found that attaching my "cleanup" memory context to PortalContext with some
elogs() shows that it appears to be called correctly just before the portal
is destroyed - so whatever I finally come up with is likely to be a
combination of the two methods. I will dig further into the function  code
and see how I manage.


Many thanks,

Mark.

------------------------
WebBased Ltd
17 Research Way
Plymouth
PL6 8BT

T: +44 (0)1752 797131
F: +44 (0)1752 791023

http://www.webbased.co.uk   
http://www.infomapper.com 
http://www.swtc.co.uk  

This email and any attachments are confidential to the intended recipient
and may also be privileged. If you are not the intended recipient please
delete it from your system and notify the sender. You should not copy it or
use it for any purpose nor disclose or distribute its contents to any other
person.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SIGSEGV taken on 8.1 during dump/reload
Next
From: shenanigans
Date:
Subject: [OTAnn] Feedback