test=# set log_statement_stats = on;
SET
test=# checkpoint;
LOG: QUERY STATISTICS
DETAIL: ! system usage stats:
! 0.100725 elapsed 0.000000 user 0.000000 system sec
! [0.000000 user 0.001999 sys total]
! 0/0 [0/0] filesystem blocks in/out
! 0/0 [0/319] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 1/1 [8/6] voluntary/involuntary context switches
! buffer usage stats:
! Shared blocks: 0 read, 0 written, buffer
hit rate = 0.00%
! Local blocks: 0 read, 0 written, buffer
hit rate = 0.00%
! Direct blocks: 0 read, 0 written
CHECKPOINT

The problematic line is "0 written" -- this is because we bgwriter is
actually the command exeuctor. So in our process, we got nothing. But maybe
not deserved a fix ...

Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Qingqing Zhou" <zhouqq (AT) cs (DOT) toronto.edu> writes:
What's your point? Those stats are correct for the current process (or
if not, better take it up with your kernel vendor) and we've never
stated that they are anything else than process-local stats. In every
version of Postgres it's been possible that pages dirtied by one process
are actually written by some other process --- the bgwriter isn't doing
anything except altering the probabilities a bit.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

"Tom Lane" <tgl (AT) sss (DOT) pgh.pa.us> wrote
I mean for other commands, the stats are real for it -- no matter it writes
out its own dirty pages or others. Because the process itself is the *only*
exeuctor. From those numbers, I can roughly figure out why it tooks that
time to finish. But for CHECKPOINT, the process actually is not the
executor.

I raise this problem because (1) I want to add a stat number for xlog
write/sync; (2) Considering we may have a background xlog writer (discussed
long time before), the stats may become pointless for local process.

Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"Qingqing Zhou" <zhouqq (AT) cs (DOT) toronto.edu> writes:
The bgwriter is already capable of pushing xlog data to disk --- it must
do so to guarantee the invariant that xlog hits disk before data-file
change. I think it could do with some tweaking to make it more probable
that the bgwriter issues such writes rather than a regular backend, but
it can happen now. And even without the bgwriter, xlog data your
process created could be forced to disk by some other backend if the
other backend wants to commit before you do.

I'm not entirely sure that the getrusage stats ever meant a lot for
Postgres; they're certainly a pretty incomplete view of what's going
on now.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend