Re: Performance and WAL on big inserts/updates

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Marty Scholes <marty(at)outputservices(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance and WAL on big inserts/updates
Date: 2004-03-12 02:12:12
Message-ID: 1079057531.86715.127.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-03-12 02:29:51 Re: Default Stats Revisited
Previous Message Marty Scholes 2004-03-12 02:04:37 Re: Performance and WAL on big inserts/updates