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

Re: Fast index build vs. PITR

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fast index build vs. PITR
Date: 2004-06-01 20:29:12
Message-ID: 1086121751.3258.266.camel@stromboli (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2004-06-01 at 03:13, Alvaro Herrera wrote:
> A completely different idea would be to log a "logical index creation",
> so that during normal recovery those entries are saved somewhere; after
> the rest of WAL recovery is done, the system is taken into a more normal
> post-recovery pre-usable state, on which those indexes are recreated
> from user data.  This would be cheapest in WAL traffic, but probably
> it'll also require more code and new hooks in the startup mechanism.
> Also, it'd require examining later WAL entries that refer to the index
> and act accordingly (e.g. ignore the entry if it modifies the index, and
> forget the creation if it's a DROP INDEX command.)

There will be many ways to optimise recovery once we have PITR

The current code does a straight replay of all changes. We can imagine
lots of different multi-pass or lookahead strategies for replaying xlog
records, but please lets wait awhile...

> Not that I like neither of those ideas really ... issuing normal WAL
> index creation traffic if PITR is active is certainly the easiest way.

I agree, certainly for now.

Best Regards, Simon Riggs

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2004-06-01 20:31:22
Subject: Re: Fast index build vs. PITR
Previous:From: Bruce MomjianDate: 2004-06-01 20:17:13
Subject: Re: Fast index build vs. PITR

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