Subject: Re: logging or debugging to report time to establish a database
 connection
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: <AF80C1FC-F152-45B3-8C6E-C21A2F9E6183@elevated-dev.com>
Date: Fri, 12 Jul 2013 09:53:17 -0600
Cc: pgsql-admin@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4B22C11-9FB2-484A-B85C-E025CB0E9BAF@elevated-dev.com>
References: 
 <CAB9893hsCadfaG6onDKknE5q+A+Mh4hEsjW9WD7s3WfPPcHpTA@mail.gmail.com>
 <AF80C1FC-F152-45B3-8C6E-C21A2F9E6183@elevated-dev.com>
To: Mike Broers <mbroers@gmail.com>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

BTW, just for the heck of it, I decided to try it out on my dev system (sev=
eral year old 17" MacBook Pro, meaning core i7 processor), PostgreSQL 9.2, =
pgbouncer 1.5. So, connecting via libpq to postgres directly takes 2-3 ms, =
connecting to pgbouncer takes typically 70-150 us, with the occasional outl=
ier at 500+ us--of course that's with a pgbouncer config with a big enough =
pool that I never have to wait for a connection to become free.


On Jul 12, 2013, at 9:21 AM, Scott Ribe wrote:

> On Jul 12, 2013, at 9:00 AM, Mike Broers wrote:
>=20
>> Is there something I am overlooking in postgres logging or psql client s=
witches that would make this information available or am I stuck with lower=
 level tools?
>=20
> Well, if you want to log how long pgbouncer takes to hand out a connectio=
n from a pool, you're certainly not going to find that answer anywhere in p=
ostgresql logging ;-)
>=20
> Unfortunately, it doesn't look to me as though the pgbouncer console will=
 show you exactly that. Maybe using -v or -vv options would help? But yes, =
average/max/min maybe even stddev of time to hand out a connection would se=
em to be information that would be good to collect, so perhaps a feature re=
quest is in order...
>=20
> Of course there will also be overhead in the libraries that will vary fro=
m one database manager to another, so in my opinion the only way to really =
benchmark this would be from the client side anyway. Which is maybe what yo=
u were thinking when asking about psql switches? Again, a feature request m=
ight be in order--I can think of two possibilities: 1) a command-line verbo=
se-mode switch that would provide details of the connection process, which =
could be good also for debugging connection problems, showing what host is =
being attempted, what the resolution (if any) of the host name is, connecti=
on opened or not, authentication passed or not, and so on; 2) enhancements =
to the /conninfo command to provide more details.
>=20
>=20
> --=20
> Scott Ribe
> scott_ribe@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>=20


--=20
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin