Tom Lane wrote: > Karel Zak <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
