Glen Parker <glenebob@nwlink.com> writes:
> I've re-read my original email and I just can't see how anybody got the
> idea I was suggesting to not WAL record index changes.
Mainly because the idea doesn't seem to make sense unless that's part
of the package. If you don't cut index changes out of the WAL load
then the savings on the base backup alone aren't going to be all that
exciting when you consider the total cost of PITR backup.
Furthermore, you would need some very ugly hacks on the recovery process
to make it ignore (rather than try to apply) WAL records relating to
indexes. I believe there are a fair number of cases where the recovery
process doesn't even know that a particular file is an index, because
the WAL stream doesn't tell it. The live backends generating the WAL
log entries typically know that (and could suppress the entries) but the
recovery process has only a very limited view of reality. It cannot,
for example, trust the system catalogs to be in a correct/consistent
state, so it couldn't look up the info for itself.
BTW, there's a related problem with the idea, which is that the
tools normally used to take base backups haven't got any way to
distinguish indexes from any other kind of relation.
regards, tom lane