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

Re: understanding pg_stat* numbers

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: understanding pg_stat* numbers
Date: 2005-03-31 14:28:06
Message-ID: d2h1f2$1fr2$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su> writes
> From my experiments I feel heap_blks_read is the table blocks read from
> well, sort of, and heap_blks_hit - from buffer. At least, I observed when
> 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?


In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2005-03-31 14:45:36
Subject: Re: Understanding pg_xlog
Previous:From: Christopher Kings-LynneDate: 2005-03-31 12:53:53
Subject: Re: Bug in DROP NOT NULL

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