Re: Any better plan for this query?.. - Mailing list pgsql-performance

From Tom Lane
Subject Re: Any better plan for this query?..
Date
Msg-id 20444.1242146977@sss.pgh.pa.us
Whole thread Raw
In response to Re: Any better plan for this query?..  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Any better plan for this query?..  (Greg Stark <stark@enterprisedb.com>)
Re: Any better plan for this query?..  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Dimitri
Date:
Subject: Re: Any better plan for this query?..
Next
From: Alvaro Herrera
Date:
Subject: Re: Any better plan for this query?..