> Anyway, it really doesn't matter. You're trying to save a large amount > of time that simply isn't spent in this area in PostgreSQL. fsync() > happens once with commit -- and on a busy system, a single fsync call > may be sufficient for a number of parallel backends.
I think you may be right. I suspect that most "busy" installations run a large number of "light" update/delete/insert statements.
In this scenario, the kind of logging I am talking about would make things worse, much worse.
Marty
Rod Taylor wrote:
On Thu, 2004-03-11 at 21:04, Marty Scholes wrote:
I can see that and considered it.
The seed state would need to be saved, or any particular command that is not reproducible would need to be exempted from this sort of logging.
Again, this would apply only to situations where a small SQL command created huge changes.
I would say a majority of SQL queries in most designed systems (timestamp). Not to mention the fact the statement itself may use very expensive functions -- perhaps even user functions that don't repeatably do the same thing or depend on data from other tables.
Consider a successful write to table X for transaction 2, but an unsuccessful write to table Y for transaction 1. Transaction 1 calls a function that uses information from table X -- but it'll get different information this time around.
Anyway, it really doesn't matter. You're trying to save a large amount of time that simply isn't spent in this area in PostgreSQL. fsync() happens once with commit -- and on a busy system, a single fsync call may be sufficient for a number of parallel backends.
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
