Re: Any better plan for this query?..
От | Tom Lane |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 20444.1242146977@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Any better plan for this query?..
Re: Any better plan for this query?.. |
Список | pgsql-performance |
Robert Haas <robertmhaas@gmail.com> writes: > AIUI, whenever the connection pooler switches to serving a new client, > it tells the PG backend to DISCARD ALL. But why couldn't we just > implement this same logic internally? IOW, when a client disconnects, > instead of having the backend exit immediately, have it perform the > equivalent of DISCARD ALL and then stick around for a minute or two > and, if a new connection request arrives within that time, have the > old backend handle the new connection... See previous discussions. IIRC, there are two killer points: 1. There is no (portable) way to pass the connection from the postmaster to another pre-existing process. 2. You'd have to track which database, and probably which user, each such backend had been launched for; reconnecting a backend to a new database is probably impractical and would certainly invalidate all the caching. Overall it looked like way too much effort for way too little gain. regards, tom lane
В списке pgsql-performance по дате отправления: