From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Fw: query total time im milliseconds |
Date: | 2011-07-10 22:54:00 |
Message-ID: | 4E1A2D88.5040902@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 11/07/2011 2:26 AM, Radhya sahal wrote:
> long startTime = System.currentTimeMillis();
> //execute query
> long executionTime = System.currentTimeMillis() - startTime;
>
> this executionTime is not an actual time for query ,
> it includes time for access to postgresql server
> using JDBC
The pg_stat_statements contrib module in PostgreSQL 8.4 and above might
be able to do what you want. See the documentation here:
http://www.postgresql.org/docs/9.0/static/pgstatstatements.html
I don't think the core PostgreSQL server currently retains information
about how long the last query executed ran for. I thought the PL/PgSQL
"GET DIAGNOSTICS" statement might be able to find out how long the last
query run within that PL/PgSQL function took, but it can't. So I think
you're out of luck for now.
PostgreSQL *CAN* log query durations to the server log, it just doesn't
(AFAIK) offer any way to find out how long the last query took from SQL
and doesn't keep that information after the statement finishes.
--
Craig Ringer
POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2011-07-10 23:11:39 | Re: UPDATEDs slowing SELECTs in a fully cached database |
Previous Message | Craig Ringer | 2011-07-10 22:20:45 | Re: query total time im milliseconds |