Date: Wed, 6 Feb 2013 08:17:50 -0500
From: Will Platnick <wplatnick@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <2CB5B53971DB42238A7640E6EFAE8D19@gmail.com>
In-Reply-To: 
 <CABOikdPdsqgiXgq7efNCyQv6HkdFHktWAMYM0QFj8xxtBMj0Mw@mail.gmail.com>
References: <ED51F03F1D2C469EB2F7FF91C677AD4F@gmail.com>
	<CABOikdPdsqgiXgq7efNCyQv6HkdFHktWAMYM0QFj8xxtBMj0Mw@mail.gmail.com>
Subject: Re: Slow Query Help
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="511257fe_7c83e458_1c95"
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

--511257fe_7c83e458_1c95
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Good eye, I totally missed that! 

Any ideas on how to troubleshoot this delay? 


On Wednesday, February 6, 2013 at 3:51 AM, Pavan Deolasee wrote:

> On Tue, Feb 5, 2013 at 9:15 AM, Will Platnick <wplatnick@gmail.com (mailto:wplatnick@gmail.com)> wrote:
> > We upgraded from PG 9.1 to 9.2. Since the upgrade, the # of active queries
> > has raised significantly, especially during our peak time where lots of
> > users are logging in. According to New Relic, this query is now taking up
> > the most amount of time during peak activity and my pg_stat_activity and
> > slow log sampling agrees. We have 3 DB servers referenced here, production
> > running 9.2.2, semi-idle (idle except for replication when I ran the test)
> > running 9.2.2, and 9.1.3 completely idle with an old dump restored.
> > 
> 
> 
> The only thing that stands out is: on your production server I see
> "Total runtime: 7.515 ms", but the top node in EXPLAIN ANAYZE shows
> actual time as 0.179 ms. Not sure where that additional time is being
> spent though. It could be ExecutorStart/End, but have no idea why they
> should take so long.
> 
> Thanks,
> Pavan
> -- 
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
> 
> 


--511257fe_7c83e458_1c95
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>Good eye, I totally missed that=21
                </div><div><br></div><div>Any ideas on how to troubleshoo=
t this delay=3F</div>
                <div><div><br></div><div><br></div></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>On Wednesday, =46ebrua=
ry 6, 2013 at 3:51 AM, Pavan Deolasee wrote:</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div>On Tue, =46eb 5, 2013 at 9:15 AM=
, Will Platnick &lt;<a href=3D=22mailto:wplatnick=40gmail.com=22>wplatnic=
k=40gmail.com</a>&gt; wrote:</div><blockquote type=3D=22cite=22><div><div=
>We upgraded from PG 9.1 to 9.2. Since the upgrade, the =23 of active que=
ries</div><div>has raised significantly, especially during our peak time =
where lots of</div><div>users are logging in.  According to New Relic, th=
is query is now taking up</div><div>the most amount of time during peak a=
ctivity and my pg=5Fstat=5Factivity and</div><div>slow log sampling agree=
s. We have 3 DB servers referenced here, production</div><div>running 9.2=
.2, semi-idle (idle except for replication when I ran the test)</div><div=
>running 9.2.2, and 9.1.3 completely idle with an old dump restored.</div=
></div></blockquote><div><br></div><div>The only thing that stands out is=
: on your production server I see</div><div>=22Total runtime: 7.515 ms=22=
, but the top node in EXPLAIN ANAYZE shows</div><div>actual time as 0.179=
 ms. Not sure where that additional time is being</div><div>spent though.=
 It could be ExecutorStart/End, but have no idea why they</div><div>shoul=
d take so long.</div><div><br></div><div>Thanks,</div><div>Pavan</div><di=
v>-- </div><div>Pavan Deolasee</div><div><a href=3D=22http://www.linkedin=
.com/in/pavandeolasee=22>http://www.linkedin.com/in/pavandeolasee</a></di=
v></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--511257fe_7c83e458_1c95--