Re: pgsql-server: Add: > > * Allow buffered WAL writes
От | Bruce Momjian |
---|---|
Тема | Re: pgsql-server: Add: > > * Allow buffered WAL writes |
Дата | |
Msg-id | 200408140411.i7E4BEE01687@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server: Add: > > * Allow buffered WAL writes ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: pgsql-server: Add: > > * Allow buffered WAL writes
|
Список | pgsql-committers |
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? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-committers по дате отправления: