DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	b=P+RnyDqC9Arrchz10bXc0BzlreHLc6eTGG6adimFAe4fWAb55UZpGT6gNzJd/sZRfs
	Qkj2nVZngTnnQUpQoOVLcaSOQ1J8pDq7z9QSbumU23+sFcT6GIuGI1d4ONwOjb3ygwOF
	fqt3d2enADr3I5VzG2lbaNWJg0eKbTiUOhofM=
Date: Thu, 14 Jan 2010 22:23:07 +0100
From: "fkater@googlemail.com" <fkater@googlemail.com>
To: Aidan Van Dyk <aidan@highrise.ca>
Cc: pgsql-performance@postgresql.org
Subject: Re: Inserting 8MB bytea: just 25% of disk perf used?
Message-ID: <20100114212307.GD2384@comppasch2>
References: <20100114142903.GB2973@comppasch2>
	<20100114150735.GT18076@oak.highrise.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20100114150735.GT18076@oak.highrise.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)

Aidan Van Dyk:

> So, your SATA disk can do 43MB/s of sequential writes, but you're example
> is doing:
> 1) Sequential writes to WAL
> 2) Random writes to your index
> 3) Sequential writes to table heap
> 4) Sequential writes to table' toast heap
> 5) Any other OS-based FS overhead

Ok, I see. Thanks a lot for the detailed answer! Especially
writing to WAL may eat up 50% as I've learned now. So,
16MB/s x 2 would in fact be 32 MB/s, plus some extras...


However, does that mean: If I have a raw sequential
performance of 100%, I will get a binary write (like in my
example) which is about 33% as a general rule of thumb?

Just to mention:

* The system has two hard disks, the first for
  WinXP, the second purely for the postgres data.

* I was doing nothing else simultanously on the newly
  installed OS.

* The consumed time (50s, see my test case) were needed to
  99.9 % just by PGexecParam() function.

* No network connect to the postgres server (everything
  local).
  
* No complex sql command; just inserting 100x times using
  PGexecParam(), as a transaction.

* The binary data was marked as such in PGexecParam
  (Format = 1).

* What I meant by 43 MB/s "worst case": I downloaded
  some hd benchmarks which showed a performance of
  43-70 MB/s. (Whereas repetitions of my postgres test did
  never vary, but *constantly* performed at 16MB/s).

Hm.

Nevertheless: If your explanation covers all what can be
said about it then replacing the hard disk by a faster one
should increase the performance here (I'll try to check that
out).

Thanks again!

 Felix