Re: Any advice about function caching?
От | Mark Cave-Ayland |
---|---|
Тема | Re: Any advice about function caching? |
Дата | |
Msg-id | 9EB50F1A91413F4FA63019487FCD251D23931F@WEBBASEDDC.webbasedltd.local обсуждение исходный текст |
Ответ на | Re: Any advice about function caching? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: