Tom Lane wrote:
> 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.
Certainly a shared cache would be good for apps that connect to issue a
single query frequently. In such cases, there would be no local cache
to use.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
