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 по дате отправления:

Предыдущее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Any better plan for this query?..