On Wed, 21 Nov 2018 at 09:05, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Nov 16, 2018 at 11:35 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Oh! The reason I assumed it wasn't doing that is that such a behavior > > seems completely insane. If the point is to keep down the load on your > > master server, then connecting only to immediately disconnect is not > > a friendly way to do that --- even without counting the fact that you > > might later come back and connect again. > > That seems like a really weak argument. Opening a connection to the > master surely isn't free, but it must be vastly cheaper than the cost > of the queries you intend to run. I mean, no reasonable production > user of PostgreSQL opens a connection, runs one or two short queries, > and then closes the connection. You open a connection and keep it > open for minutes, hours, days, or longer, running hundreds, thousands, > or millions of queries. The cost of checking whether you've got a > master or a standby is a drop in the bucket. > > And, I mean, if there's some scenario where what I just said isn't > true, well then don't use this feature in that particular case. > > And to enforce Robert's argument even further almost every pool implementation I am aware of has a keep alive query. So why not use the opportunity to check to see if is a primary or standby at the same time Dave Cramer da...@postgresintl.com www.postgresintl.com > >
