Re: 7.3 schedule

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