Re: pgsql-server: Add: > > * Allow buffered WAL writes
От | Bruce Momjian |
---|---|
Тема | Re: pgsql-server: Add: > > * Allow buffered WAL writes |
Дата | |
Msg-id | 200408140409.i7E492401265@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server: Add: > > * Allow buffered WAL writes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
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.) > > Again, the fact that Oracle offers such a feature doesn't make it a good > idea. Agreed. I was addressing his second question: > > Is there also a possibility to tell Postgres : "I don't care if I lose 30 > > seconds of transactions on this table if the power goes out, I just want > > to be sure it's still ACID et al. compliant but you can fsync less often > > and thus be faster" (with a possibility of setting that on a per-table > > basis) ? I disagree on the per-table part but I can see cases where this middle mode would be useful. -- 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 по дате отправления: