On Sat, 14 Aug 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:On Sat, 14 Aug 2004, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
