Re: Inserting 8MB bytea: just 25% of disk perf used?

From: "fkater(at)googlemail(dot)com" <fkater(at)googlemail(dot)com>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Inserting 8MB bytea: just 25% of disk perf used?
Date: 2010-01-14 21:23:07
Message-ID: 20100114212307.GD2384@comppasch2
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Carlo Stonebanks 2010-01-14 21:25:00 New server to improve performance on our large and busy DB - advice? (v2)
Previous Message Scott Marlowe 2010-01-14 21:22:09 Re: new server I/O setup