Re: CommitDelay performance improvement

> At 23:14 23/02/01 -0500, Bruce Momjian wrote:
> >
> >There is one more thing. Even though the kernel says the data is on the
> >platter, it still may not be there.
>
> This is true, but it does not mean we should say 'the disk is slightly
> unreliable, so we can be too'. Also, IIRC, the last time this was
> discussed, someone commented that buying expensive disks and a UPS gets you
> reliability (barring a direct lightining strike) - it had something to do
> with write-ordering and hardware caches. In any case, I'd hate to see DB
> design decisions based closely on harware capability. At least two of my
> customers use high performance ram disks for databases - do these also
> suffer from 'flush is not really flush' problems?

Well, I am saying we are being pretty rigid here when we may be on top
of a system that is not, meaning that our rigidity is buying us little.

>
> >Basically, I am not sure how much we lose by doing the delay after
> >returning COMMIT, and I know we gain quite a bit by enabling us to group
> >fsync calls.
>
> If included, this should be an option only, and not the default option. In
> fact I'd quite like to see such a feature, although I'd not only do a
> 'flush every X ms', but I'd also do a 'flush every X transactions' - this
> way a DBA can say 'I dont mind losing the last 20 TXs in a crash'. Bear in
> mind that on a fast system, 20ms is a lot of transactions.

Yes, I can see this as a good option for many users. My old complaint
was that we allowed only two very extreme options, fsync() all the time,
or fsync() never and recover from a crash.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026