From: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
---|---|
To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: understanding pg_stat* numbers |
Date: | 2005-04-01 07:54:30 |
Message-ID: | Pine.GSO.4.62.0504011111340.14187@ra.sai.msu.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Qingqing,
Thanks for the info, I do know all issues you mentioned. I want to know
if there is any possibility to research performance problem in PostgreSQL
without voodoo techiques, at least at the level of pg itself. At this aspect,
I could answer myself: heap_blks_read is the # of blocks
'ordered' to read from disk and heap_blks_hit is the # of blocks
read from pg buffers.
One mystery remains, why stats show heap_blks_read > 0 for indexed search ?
select 1 from foo where id=5
I did pg_stat_reset() before run query.
Oleg
On Thu, 31 Mar 2005, Qingqing Zhou wrote:
>
> "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)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(at)postgresql(dot)org
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From | Date | Subject | |
---|---|---|---|
Next Message | Russell Smith | 2005-04-01 08:01:35 | Re: Name change proposal |
Previous Message | Michael Fuhr | 2005-04-01 07:40:19 | Name change proposal |