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
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 |