From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksei Arefjev <aleksei(dot)arefjev(at)nordicgaming(dot)com>, Richard Huxton <dev(at)archonet(dot)com> |
Subject: | Re: transactions start time |
Date: | 2012-07-25 17:01:17 |
Message-ID: | 201207251901.18070.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On Wednesday, July 25, 2012 04:56:20 PM Tom Lane wrote:
> Aleksei Arefjev <aleksei(dot)arefjev(at)nordicgaming(dot)com> writes:
> > On 24 July 2012 20:21, Richard Huxton <dev(at)archonet(dot)com> wrote:
> >> I'm not sure if I'm reading this right, but are there more than 48
> >> million BEGINs that took 0s each (presumably rounded down) and then a
> >> handful taking about 0.8s?
>
> I'm wondering exactly where/how the duration was measured. If it was at
> a client, maybe the apparent delay had something to do with network
> glitches? It seems suspicious that all the outliers are around 0.8s.
> It would be useful to look to see if there's any comparable pattern
> for statements other than BEGIN.
>
> As Richard says, a BEGIN by itself ought to take negligible time.
He earlier also asked on the IRC-Channel and I got the idea that the problem
could be explained by pgbouncer in transaction pooling mode waiting for a free
backend connection. Aleksei confirmed that they use pgbouncer in that
configuration, so that might be it.
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Marcus Engene | 2012-07-25 18:11:55 | Re: odd planner again, pg 9.0.8 |
Previous Message | Tom Lane | 2012-07-25 16:39:09 | Re: odd planner again, pg 9.0.8 |