From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] O_DIRECT for WAL writes |
Date: | 2005-06-24 13:37:23 |
Message-ID: | 26018.1119620243@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> ... So I'll post the new results:
> checkpoint_ | writeback |
> segments | cache | open_sync | fsync=false | O_DIRECT only | fsync_direct | open_direct
> ------------+-----------+-----------+---------------+---------------+---------------+--------------
> [3] 3 | off | 38.2 tps | 138.8(+263.5%)| 38.6(+ 1.2%) | 38.5(+ 0.9%) | 38.5(+ 0.9%)
Yeah, this is about what I was afraid of: if you're actually fsyncing
then you get at best one commit per disk revolution, and the negotiation
with the OS is down in the noise.
At this point I'm inclined to reject the patch on the grounds that it
adds complexity and portability issues, without actually buying any
useful performance improvement. The write-cache-on numbers are not
going to be interesting to any serious user :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-06-24 13:41:32 | Re: [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle |
Previous Message | Tom Lane | 2005-06-24 13:27:23 | Re: Fixing r-tree semantics |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-06-24 13:41:32 | Re: [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle |
Previous Message | Tom Lane | 2005-06-24 13:21:25 | Re: [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle vararg polymorphic functions) |