Re: Fast index build vs. PITR

> 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