Обсуждение: Slow Query Help

On 05.02.2013 05:45, Will Platnick wrote:
> We upgraded from PG 9.1 to 9.2. Since the upgrade, the # of active queries has raised significantly, especially
duringour peak time where lots of users are logging in.  According to New Relic, this query is now taking up the most
amountof time during peak activity and my pg_stat_activity and slow log sampling agrees. We have 3 DB servers
referencedhere, production running 9.2.2, semi-idle (idle except for replication when I ran the test) running 9.2.2,
and9.1.3 completely idle with an old dump restored. 

The only thing that stands out is that it always checks both indexes for
matches. Since you only want a single row as a result, it seems like it
would be better to first check one index, and only check the other one
if there's no match. Rewriting the query with UNION should do that:

SELECT id, username, password, email, verified, timezone FROM users
WHERE lower(username) = 'randomuser'
UNION ALL
SELECT id, username, password, email, verified, timezone FROM users
WHERE lower(email) = 'randomuser'
LIMIT 1;

Also, if you can assume that email addresses always contain the
@-character, you could take advantage of that and only do the
lower(email) = 'randomuser' search if there is one.

- Heikki

On Tue, Feb 5, 2013 at 9:15 AM, Will Platnick <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

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> 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

Will Platnick <wplatnick@gmail.com> wrote:
> Will Platnick <wplatnick@gmail.com> wrote:

>> 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.

> Any ideas on how to troubleshoot this delay?

Is the client which is running the query on the same machine as the
server?  If not, what's the ping time between them?

-Kevin

On Wednesday, February 6, 2013 at 11:22 AM, Kevin Grittner wrote:

Will Platnick <wplatnick@gmail.com> wrote:

Will Platnick <wplatnick@gmail.com> wrote:

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.

Any ideas on how to troubleshoot this delay?

Is the client which is running the query on the same machine as the

server?  If not, what's the ping time between them?

-Kevin

On Wed, Feb 6, 2013 at 9:52 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Will Platnick <wplatnick@gmail.com> wrote:
>> Will Platnick <wplatnick@gmail.com> wrote:
>
>>> 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.
>
>> Any ideas on how to troubleshoot this delay?
>
> Is the client which is running the query on the same machine as the
> server?  If not, what's the ping time between them?
>

I don't think the network latency can cause that. The "Total runtime"
is calculated on the server side itself - see ExplainOnePlan().

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee