Re: WAL Bypass for indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "Martin Scholes" <marty(at)iicolo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL Bypass for indexes
Date: 2006-04-03 01:32:13
Message-ID: 26766.1144027933@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> I guess I can think of a few instances, but none that I would've
> chosen to use it in. IIRC, it's also more likely to increase the cost
> of checkpointing and/or require a good amount of bgwriter tuning.

How so? AFAICS it'd just eliminate WAL output.

> As long as it's optional, I guess it's OK to let the administrator
> deal with recovery.

As I understood it, the proposal was for a feature that would arrange
for the required index rebuild to happen *automatically* during crash
recovery. I agree it'd be unacceptable if it requires manual
intervention at restart.

It occurs to me that if we had such a behavior, we could use it to "fix"
hash indexes to be crash-safe, with less effort than WAL-ifying the hash
code: just put in a small kluge to mark all hash indexes as needing
rebuild during recovery. Not that I'm against teaching hash to do WAL,
but no one's stepped up to the plate on that yet.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-04-03 01:34:54 Re: semaphore usage "port based"?
Previous Message Marc G. Fournier 2006-04-03 01:31:39 Re: semaphore usage "port based"?