From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Jan de Visser
One thing that's probably key here is that pgsql isn't multi-threaded. Individual connections are handled by forked backends, which share a shared- memory cache that's not accessible by SQL-land code (which includes language handlers). So I think your problem goes away once you realize that all the data you have is tied to a single connection anyway. [dmb>] [dmb>] Thanks. Yes, I knew that. My problem is a strategy to start up the language engine once (per session), load stuff from the database once, and then keep the per-call cost as low as possible. I know that palloc() memory goes away; that it has a lifetime longer than a function invocation and should span a recursive function call, but definitely not longer than a transaction. So I need to get some memory per session and keep a pointer to it per session (which it seems is per process). You cannot use multi-threaded code (which touches the database) in language handlers or other "plug-in" code. [dmb>] That's good -- I hate threads. I've never been able to figure out how to test them adequately. No loss there. Also, trying to outsmart the db engine's cache by building your own is usually an exercise in futility and often counter-productive. I speak from experience :-P [dmb>] Isn't cache invalidation the second hardest thing in computing (after naming things)? [dmb>] Seems like DLL static memory with allocation from process memory (or even malloc()) is "the simplest thing that could possibly work". Regards David M Bennett FACS Andl - A New Database Language - andl.org -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
