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

Re: Fast index build vs. PITR

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fast index build vs. PITR
Date: 2004-06-01 12:59:54
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA40184D0EE@m0114.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> I think an actually implementable version of this would be:
> 
> 1. Don't log any index operations at all in WAL.
> 
> 2. When recovering from WAL, restore all the table contents by WAL
> replay.  (This would of course include the system catalog contents that
> describe the indexes.)  Then sit there and do a global REINDEX to
> rebuild all the indexes.
> 
> This would gain a reduction of some percentage in WAL traffic, at the
> cost of a hugely expensive recovery cycle any time you actually needed
> to use the WAL.  I guess this could be attractive to some installations,
> but I'm not sure very many people would want it ...

I think only the "global" part of it is not really acceptable. If we had a flag
for each index that marks it "inconsistent" reindexing only those that are
marked would be great.

Could we log a WAL record that basically only marks an index for deferred reindex
after WAL recovery ? During WAL replay all records for this index could be 
ignored (this is not a must because of the post update page images in WAL, 
the index would still stay inconsistent until reindex of course).

I think such a reindex step could also be responsible for those non-btree 
indexes that don't fully support WAL (gist?).

Andreas

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-06-01 13:42:46
Subject: Re: Fast index build vs. PITR
Previous:From: Bob.HenkelDate: 2004-06-01 12:56:05
Subject: Re: Nested xacts: looking for testers and review

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