Joe Conway <mail@joeconway.com> writes:
> Jessica Blank wrote:
>> So I guess what I'm saying is that I don't care so much about CPU time, or
>> I/O time, but *TOTAL* time. How long it takes from the instant the query
>> hits Postgres to the instant I get my results back...
> That's pretty much exactly what EXPLAIN ANALYZE does for you. And along with
> it, you get other useful information to help you improve the query.
Also, in 7.3 psql has a "\timing" setting that automatically gives you
elapsed time for each query.
I concur with the recommendation to pay more attention to elapsed time
than CPU time (even if you could get the latter, which you can't
easily).
If you really feel a need for CPU time, you could turn on
"log_statement_stats" (that's what current sources call it anyway,
but I think Bruce renamed it from something else recently) and then
look in the postmaster log for entries like so:
LOG: QUERY STATISTICS
! system usage stats:
! 3.843989 elapsed 2.220000 user 0.340000 system sec
! [2.260000 user 0.360000 sys total]
! 1797/0 [1874/4] filesystem blocks in/out
! 0/0 [0/1] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/144 [5/149] messages rcvd/sent
! 1410/238 [1458/246] voluntary/involuntary context switches
! buffer usage stats:
! Shared blocks: 1799 read, 0 written, buffer hit rate = 7.08%
! Local blocks: 0 read, 0 written, buffer hit rate = 0.00%
! Direct blocks: 0 read, 0 written
But I think EXPLAIN ANALYZE is much more useful.
regards, tom lane