On Tue, Jul 27, 2010 at 4:40 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> On Thu, Jul 22, 2010 at 5:29 PM, Andres Freund <andres@xxxxxxxxxxx> wrote: >>>> The problem is harder for us because a backend can't switch identities >>>> once it's been assigned to a database. I haven't heard an adequate >>>> explanation of why that couldn't be changed, though. > >>> Possibly it might decrease the performance significantly enough by >>> reducing the cache locality (syscache, prepared plans)? > >> Those things are backend-local. The worst case scenario is you've got >> to flush them all when you reinitialize, in which case you still save >> the overhead of creating a new process. > > "Flushing them all" is not zero-cost; it's not too hard to believe that > it could actually be slower than forking a clean new backend. I'm not so sure I believe that. Is a sinval overrun slower than forking a clean new backend? Is DISCARD ALL slower that forking a clean new backend? How much white space is there between either of those and what would be needed here? I guess it could be slower, but I wouldn't want to assume that without evidence. > What's much worse, it's not zero-bug. We've got little bitty caches > all over the backend, including (no doubt) some caching behavior in > third-party code that wouldn't get the word about whatever API you > invented to deal with this. I think this is probably the biggest issue with the whole idea, and I agree there would be some pain involved. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
