PL Caching in TopTransactionContext - Mailing list pgsql-hackers

From
Subject PL Caching in TopTransactionContext
Date
Msg-id 4016450.1160043141957.JavaMail.root@fep06.ttnet.net.tr
Whole thread Raw
Responses Re: PL Caching in TopTransactionContext  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

I've been planning to implement a caching mechanism for non-volatile
(and non-SRF) procedures in PL/scheme, that'll return pre-computed
values in case of a procedure signature overlap[1].

First, I decided to use fcinfo->flinfo->fn_mcxt context for the storage.
But then I learnt it'll survive as long as FmgrInfo will do, which means
that (I think) it can only be useful for subsequent calls in the current
query context. (Like when returning from a SRF.) Right? (An explanation
for the possible use cases of this memory context will be appreciated.)

And after reading backend/utils/mmgr/README, I think
TopTransactionContext is the way for me to go. Actually, I can use
CurTransactionContext too, but why should I make a redundant computation
of a non-volatile procedure that might be probably computed before in
the TopTransactionContext. (Yeah, same is true for TopMemoryContext too,
but IMHO that's not something a PL handler should mess with.) OTOH,
"this[TopTransactionContext] context is NOT cleared immediately upon
error; its contents will survive until the transaction block is exited
by COMMIT/ROLLBACK." note in the README makes me consider again using
CurTransactionContext instead.

I wanted to consult this decision to the developers. Is
TopTransactionContext the way for me to go? Should I prefer considering
a totally different implementation?

And one last question: After a successful establishment of this
mechanism in PL/scheme, I can try to port it to PL/pgSQL. Will
developers welcome such a patch?


Regards.


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: workaround for buggy strtod is not necessary
Next
From: Lukas Kahwe Smith
Date:
Subject: Re: 8.2 beta blockers