Re: why does reindex invalidate relcache without modifying system tables
От | wenjing zeng |
---|---|
Тема | Re: why does reindex invalidate relcache without modifying system tables |
Дата | |
Msg-id | FAC7515D-B472-4DAD-A095-6066E19A3B78@gmail.com обсуждение исходный текст |
Ответ на | Re: why does reindex invalidate relcache without modifying system tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> 2021年12月27日 23:54,Tom Lane <tgl@sss.pgh.pa.us> 写道: > > 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 Thank you for your explanation, which clears up my doubts. Wenjing
В списке pgsql-hackers по дате отправления: