PL Caching in TopTransactionContext

From: <yazicivo(at)ttnet(dot)net(dot)tr>
To: pgsql-hackers(at)postgresql(dot)org
Subject: PL Caching in TopTransactionContext
Date: 2006-10-05 10:12:21
Message-ID: 4016450.1160043141957.JavaMail.root@fep06.ttnet.net.tr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Kahwe Smith 2006-10-05 12:05:32 Re: 8.2 beta blockers
Previous Message Zdenek Kotala 2006-10-05 09:01:45 Re: workaround for buggy strtod is not necessary