[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] understanding pg_stat* numbers
From:       "Qingqing Zhou" <zhouqq () cs ! toronto ! edu>
Date:       2005-03-31 14:28:06
Message-ID: d2h1f2$1fr2$1 () news ! hub ! org
[Download RAW message or body]


"Oleg Bartunov" <oleg@sai.msu.su> writes
> From my experiments I feel heap_blks_read is the table blocks read from
disk,
> well, sort of, and heap_blks_hit - from buffer. At least, I observed when
I
> repeat the same query several times (heap_blks_read+heap_blks_hit) doesn't
> changed while more blocks come from heap_blks_hit.
>

PG relies on the OS to schedule the *real* IO you mean. So heap_blks_read
may come from OS kernel buffer, or from disk. You can minimize/disable your
OS file buffers (if it supports this function) or change the mdopen() using
O_DIRECT to make the heap_blks_read approaches the *real* IO if you want -
but for sure this hurts performance.

> It's common in db worlds to have IO statistics (timings are not important)
> to research algorithms and implementation.
>

The *real* IO you mean might be an elegant choice in academic, but is a
subjective matter in practice. For example, we can only assume statistically
N random IO costs the same time with another N random IO, because disk
header has its own scheduling logic controlled by the layout of these
blocks, etc, which you can't decide. Not to speak of the IOs in concurrent
environment.  If so, use heap_blks_read/write is already good enough?

Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
[prev in list] [next in list] [prev in thread] [next in thread]