On Fri, 13 Aug 2004, Bruce Momjian wrote:
Tom Lane wrote:Bruce Momjian <[EMAIL PROTECTED]> writes:Tom Lane wrote:Who exactly signed onto this as a good idea? It sure doesn't square with my ideas of an ACID database. Committed means committed, not "maybe if you're lucky committed".
True but we support fsync. Certainly it would be more useful than fsync, and it might allow us to remove fsync.
How so? fsync off is for I-don't-care-about-this-data-at-all cases (primarily development, though loading already-archived data can qualify too). I'm not seeing a use-case for "I care about this data, but only once it's more than N seconds old". It certainly does not replace "just go as fast as you can", which is what fsync off means.
No one has to sign TODO items, BTW. They are added and removed as requested.
[ shrug... ] So if I request removal of this item, it will go away again? It hasn't reached the age needed to guarantee commit ;-)
Many databases offer this feature. The submitter asked for it, and I think it is a good idea. For cases where you are running an in-house app, you can tell your employees to re-key the stuff they did just before the crash. It doesn't work for web apps and stuff, but for smaller cases it is fine.
With Informix, the logic used by most customers I dealt with was that unbuffered logging was too slow and they were willing to do a few rekeys for the performance gain.
I tend to agree with Tom that this is a bad idea, but ... if we do foolishly implement this, can it be a disfeature that is only available via a special configure flag on compile, that creates a special GUC variable that defaults to the standard behaviour?
Basically, if you desire to risk cutting off your left hand for the sake of speed, put them through a couple of hoops to get there first ...
---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
