Skip site navigation (1) Skip section navigation (2)

Re: Cost of XLogInsert CRC calculations

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>,Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>,'Manfred Koizar' <mkoi-pg(at)aon(dot)at>,'Bruce Momjian' <pgman(at)candle(dot)pha(dot)pa(dot)us>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Cost of XLogInsert CRC calculations
Date: 2005-06-01 08:50:09
Message-ID: 1117615809.3844.893.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2005-05-31 at 22:36 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Hmmm. I seem to recall asking myself why xl_prev existed if it wasn't
> > used, but passed that by. Damn.
> 
> I couldn't believe it'd been overlooked this long, either.  It's the
> sort of thing that you assume got done the first time :-(

Guess it shows how infrequently PostgreSQL crashes and recovers.

> > PreAllocXLog was already a reason to have somebody prepare new xlog
> > files ahead of them being used. Surely the right solution here is to
> > have that agent prepare fresh/zeroed files prior to them being required.
> 
> Uh, why?  That doubles the amount of physical I/O required to maintain
> the WAL, and AFAICS it doesn't really add any safety that we can't get
> in a more intelligent fashion.

OK, I agree that the xl_prev linkage is the more intelligent way to go.

If I/O is a problem, then surely you will agree that PreAllocXLog is
still required and should not be run by a backend? Thats going to show
as a big response time spike for that user.

Thats the last bastion - the other changes are gonna smooth response
times right down, so can we do something with PreAllocXLog too?

Best Regards, Simon Riggs


In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2005-06-01 08:57:26
Subject: Re: Can we simplify win32 threading code
Previous:From: Greg StarkDate: 2005-06-01 08:44:24
Subject: Re: NOLOGGING option, or ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group