Bruce Momjian wrote:
> Jonah H. Harris wrote:
>> On 2/27/07, Josh Berkus <josh@agliodbs.com> wrote:
>>> You're missing my point, which is that nobody has demonstrated that there
>>> is any real performance gain from this. I see no reason to implement it
>>> if there is no performance gain.
>> While I'll back your request for results, it seems nearly impossible
>> to expect no performance gain using this.
>>
>> Results never hurt though.
>
> The results are going to be very close to fsync off for sufficiently
> high values delay, and we _know_ fsync off is a performance win.
This is an assumption. Yes we know that fsync off is a performance win.
We do not know that COMMIT NO WAIT is a performance win. Yes, we can all
sit here and stare at what we *think* will be the result and yes I
actually concur that it will be a performance win.
However, I strongly concur that we need at least some evidence. It could
easily be that a misstep in the code, causes a loop over the wrong set
and all the performance we thought we would get is invalid, not because
of theory or what should happen, but because of actual implementation.
Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
