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

Re: Fast index build vs. PITR

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fast index build vs. PITR
Date: 2004-06-01 17:21:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 01, 2004 at 12:52:32PM -0400, Greg Stark wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > I thought for a little bit about a magic "reconstruct the index" WAL
> > entry that would invoke the index build procedure in toto, but that
> > doesn't look like it will fly either.  (Two problems: during crash
> > recovery, you couldn't be sure that what's on disk for the underlying
> > table exactly matches the index you need to build --- it could be a
> > later state of the table; and besides, the environment of the WAL replay
> > process isn't capable of running user-defined functions, so it couldn't
> > work for functional indexes.)
> Could you just mark the index as unusable? Have the optimizer ignore such
> indexes and PITR recovery can notify the user of these indexes and/or invoke a
> rebuild automatically?

The big problem I see with this kind of approaches is that building an
index from scratch can take a huge amount of time, because you have to
sort the data.  Building from WAL does not have this problem, so it can
be much faster.  Of course, when you are restoring using a PITR
approach you probably want it to be very fast, and have the DB running
with as little quirks as possible, as soon as possible.

Alvaro Herrera (<alvherre[a]>)
"El realista sabe lo que quiere; el idealista quiere lo que sabe" (AnĂ³nimo)

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-06-01 17:26:04
Subject: Re: Official Freeze Date for 7.5: July 1st, 2004
Previous:From: Marc G. FournierDate: 2004-06-01 16:57:44
Subject: Re: Official Freeze Date for 7.5: July 1st, 2004

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