On Sat, 14 Aug 2004, Bruce Momjian wrote:
> Marc G. Fournier wrote:
>> On Sat, 14 Aug 2004, Tom Lane wrote:
>>
>>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> Many databases offer this feature. The submitter asked for it,
>>>
>>> Actually he didn't --- AFAICS you misinterpreted the thread completely.
>>> The original suggestion was that we might be able to exploit a
>>> transactional filesystem to improve performance *without* sacrificing
>>> any correctness guarantees. Delayed fsync has nothing to do with that.
>>>
>>> (I'm dubious whether there's any performance improvement to be had that
>>> would be worth the code uglification involved, since we're surely not
>>> going to *require* a transactional filesystem and so two very different
>>> code paths seem to be needed. But it's at least something to think about.)
>>
>> Just to expand on the 'dubiousness' ... remember awhile back when I worked
>> through the 'no-WAL' version of PostgreSQL to test loading a database with
>> WAL disabled? The performance improvements on loading a database weren't
>> enough, I seem to recall, to warrant getting rid of WAL altogether ... so
>> I can't see 'delayed WAL' being faster then 'no WAL' ...
>
> Uh, you mean fsync isn't a performance hit as it once was?
No, I mean that writing WAL doesn't appear to be a performance hit ...
removing WAL writing and doing a large db load, the load is a bit faster,
but not as big as one would hope ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664