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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html