Re: can't handle large number of INSERT/UPDATEs

From: John Meinel <john(at)johnmeinel(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Curtis Zinzilieta <curtisz(at)norchemlab(dot)com>, Anjan Dave <adave(at)vantage(dot)com>, Matt Clark <matt(at)ymogen(dot)net>, Rod Taylor <pg(at)rbt(dot)ca>, Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: can't handle large number of INSERT/UPDATEs
Date: 2004-10-27 04:18:09
Message-ID: 417F2181.4000801@johnmeinel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane wrote:
> Curtis Zinzilieta <curtisz(at)norchemlab(dot)com> writes:
>
>>On Tue, 26 Oct 2004, Tom Lane wrote:
>>
>>>Er ... it *is* the other way around. bi is blocks in (to the CPU),
>>>bo is blocks out (from the CPU).
>
>
>>Ummm.....
>>[curtisz(at)labsoft T2]$ man vmstat
>> bi: Blocks sent to a block device (blocks/s).
>> bo: Blocks received from a block device (blocks/s).
>
>
> You might want to have a word with your OS vendor. My vmstat
> man page says
>
> IO
> bi: Blocks received from a block device (blocks/s).
> bo: Blocks sent to a block device (blocks/s).
>
> and certainly anyone who's been around a computer more than a week or
> two knows which direction "in" and "out" are customarily seen from.
>
> regards, tom lane
>

Interesting. I checked this on several machines. They actually say
different things.

Redhat 9- bi: Blocks sent to a block device (blocks/s).
Latest Cygwin- bi: Blocks sent to a block device (blocks/s).
Redhat 7.x- bi: Blocks sent to a block device (blocks/s).
Redhat AS3- bi: blocks sent out to a block device (in blocks/s)

I would say that I probably agree, things should be relative to the cpu.
However, it doesn't seem to be something that was universally agreed
upon. Or maybe the man-pages were all wrong, and only got updated recently.

John
=:->

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Iain 2004-10-27 05:02:48 Re: can't handle large number of INSERT/UPDATEs
Previous Message Tom Lane 2004-10-27 03:21:31 Re: can't handle large number of INSERT/UPDATEs