From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Subject: | Re: COMMIT NOWAIT Performance Option |
Date: | 2007-02-28 01:51:04 |
Message-ID: | 87odnfoxrr.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> OK. I've seen no performance numbers yet though. It just seems to me that
> any performance patch proposal should start a discussion of what amount of
> performance we expect to gain.
There exist proposals that can be prototyped and measured to see what
potential they have. I don't see how this is one of them though. The only way
I could see to prototype this is would, as Bruce said, be to turn fsync off
and consider that the extreme end of the spectrum. The reality will lie
somewhere in between and exactly where will depend on the value of the delay.
> Unfortunately, this is *not* a patch I can test on TPCE or SpecJ, because both
> of those have ACID requirements which I don't think this would satisfy. I'd
> have to modify the benchmark, and I already have 4 performance patches queue
> which don't require that.
I haven't read TPCE but if it's like TPCC then the simple addition of a UPS
satisfies the ACID requirements even with fsync off entirely. Pretty lame but
it's explicitly sufficient.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2007-02-28 01:51:19 | Re: [HACKERS] |
Previous Message | Josh Berkus | 2007-02-28 01:50:28 | Re: COMMIT NOWAIT Performance Option |