From: | Marty Scholes <marty(at)outputservices(dot)com> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance and WAL on big inserts/updates |
Date: | 2004-03-12 02:47:37 |
Message-ID: | 405124C9.1000809@outputservices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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 majordomo(at)postgresql(dot)org)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2004-03-12 03:06:17 | Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org |
Previous Message | Marty Scholes | 2004-03-12 02:45:26 | Re: Performance and WAL on big inserts/updates |