From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | wenjing zeng <wjzeng2012(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: why does reindex invalidate relcache without modifying system tables |
Date: | 2021-12-27 15:54:25 |
Message-ID: | 1487949.1640620465@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
wenjing zeng <wjzeng2012(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Isaac Morland | 2021-12-27 16:03:43 | Re: Foreign key joins revisited |
Previous Message | Sascha Kuhl | 2021-12-27 15:28:43 | Re: Foreign key joins revisited |