Karel Zak <zakkr@zf.jcu.cz> writes:
> * The patch allows store query-planns to shared memory and is
> possible EXECUTE it at more backends (over same DB) and planns
> are persistent across connetions. For this feature I create special
> memory context subsystem (like current aset.c, but it works with
> IPC shared memory).
> This is maybe too complex solution and (maybe) sufficient is cache
> query in one backend only. I know unbelief about this shared
> memory solution (Tom?).
Yes, that is the part that was my sticking point last time around.
(1) Because shared memory cannot be extended on-the-fly, I think it is
a very bad idea to put data structures in there without some well
thought out way of predicting/limiting their size. (2) How the heck do
you get rid of obsoleted cached plans, if the things stick around in
shared memory even after you start a new backend? (3) A shared cache
requires locking; contention among multiple backends to access that
shared resource could negate whatever performance benefit you might hope
to realize from it.
A per-backend cache kept in local memory avoids all of these problems,
and I have seen no numbers to make me think that a shared plan cache
would achieve significantly more performance benefit than a local one.
regards, tom lane
