Re: Fast index build vs. PITR

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Fast index build vs. PITR
Дата
Msg-id 87k6yr6x0v.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Fast index build vs. PITR  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fast index build vs. PITR  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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?

It wouldn't happen unless the user had done an index rebuild since the last
complete backup, so it wouldn't even be a performance issue. Restoring the
index from the WAL replay of an index rebuild must take a long time anyways.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Win32, PITR, nested transactions, tablespaces
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: Official Freeze Date for 7.5: July 1st, 2004