Re: Proposed LogWriter Scheme, WAS: Potential Large Performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Curtis Faith <curtis(at)galtair(dot)com>, Pgsql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposed LogWriter Scheme, WAS: Potential Large Performance
Date: 2002-10-05 23:03:41
Message-ID: 6061.1033859021@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Or its solution ;) as instead of the predicting we just write all data
> in log that is ready to be written. If we postpone writing, there will
> be hickups when we suddenly discover that we need to write a whole lot
> of pages (fsync()) after idling the disk for some period.

This part is exactly the same point that I've been proposing to solve
with a background writer process. We don't need aio_write for that.
The background writer can handle pushing completed WAL pages out to
disk. The sticky part is trying to gang the writes for multiple
transactions whose COMMIT records would fit into the same WAL page,
and that WAL page isn't full yet.

The rest of what you wrote seems like wishful thinking about how
aio_write might behave :-(. I have no faith in it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mitch 2002-10-05 23:31:46 Mailing list unsubscribe - hackers isn't there?
Previous Message Antoine Lobato 2002-10-05 22:05:03 Implicit Lock Row