Skip site navigation (1) Skip section navigation (2)

Re: query execution time

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <julius(at)nsoft(dot)lt>,<pgsql-admin(at)postgresql(dot)org>
Subject: Re: query execution time
Date: 2010-10-07 17:09:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Julius Tuskenis <julius(at)nsoft(dot)lt> wrote:
> we connect to localhost on windows machine because we 
> use ssh tunel to the postgresql server on gentoo linux.
Latency in the extra hop or from encryption/decryption of the
streams could account for at least some of the difference between
how long it took the server to run the query versus the elapsed time
between when the client started sending it out and when it got the
last of the response.
> The DB is used for web application writen in PHP. As the DB and
> WEB servers are on the same machine we can rule out the network
> issues I guess...
What you can't rule out is the possibility that the web app thread
reading the response doesn't get a time slice for some time after
the database is done.
> The behavior described is observed when there is high server
> usage.  Using "server status" tool shows several such queries
> executed suddenly and then after some waiting everything goes back
> to normal.
Can you run `vmstat 1` and see what it shows during an episode? 
This could be particularly valuable if you can timestamp the lines
to compare to log entries.  You might want to turn on checkpoint
Again, we don't know anything about the amount of RAM, your
postgresql.conf settings, your disk subsystem (particularly your
RAID adapter and its configuration), etc.  With more information we
can give better advice.

pgsql-admin by date

Next:From: AndreasDate: 2010-10-08 03:42:40
Subject: 5 pg_toast_temp and pg_temp schemas ?
Previous:From: Kiswono PrayogoDate: 2010-10-07 16:58:18
Subject: installation failed for PostgreSQL 9.0.0 in Windows (Visual C++ Runtime Installation error)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group