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?

>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.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/