Re: why does reindex invalidate relcache without modifying system tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: why does reindex invalidate relcache without modifying system tables
Дата
Msg-id 1487949.1640620465@sss.pgh.pa.us
обсуждение исходный текст
Ответ на why does reindex invalidate relcache without modifying system tables  (wenjing zeng <wjzeng2012@gmail.com>)
Ответы Re: why does reindex invalidate relcache without modifying system tables  (wenjing zeng <wjzeng2012@gmail.com>)
Список pgsql-hackers
wenjing zeng <wjzeng2012@gmail.com> writes:
> I found that in the index_update_stats function, i.e. the CREATE INDEX/REINDEX/Truncate INDEX process,
> relchche is invalidated whether the index information is updated. I want to know why you're did this

Did you read the function's header comment?  It says

 * NOTE: an important side-effect of this operation is that an SI invalidation
 * message is sent out to all backends --- including me --- causing relcache
 * entries to be flushed or updated with the new data.  This must happen even
 * if we find that no change is needed in the pg_class row.  When updating
 * a heap entry, this ensures that other backends find out about the new
 * index.  When updating an index, it's important because some index AMs
 * expect a relcache flush to occur after REINDEX.

That is, what we need to force an update of is either the relcache's
rd_indexlist list (for a table) or rd_amcache (for an index).

In the REINDEX case, we could conceivably skip the flush on the table,
but not on the index.  I don't think it's worth worrying about though,
because REINDEX will very probably have an update for the table's
physical size data (relpages and/or reltuples), so that it's unlikely
that the no-change path would be taken anyway.

            regards, tom lane



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

Предыдущее
От: Sascha Kuhl
Дата:
Сообщение: Re: Foreign key joins revisited
Следующее
От: Isaac Morland
Дата:
Сообщение: Re: Foreign key joins revisited