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
