Обсуждение: why does reindex invalidate relcache without modifying system tables

Hi Tom

I would like to ask you about the details of index build.
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
The code is:
        if (dirty)
         {
            heap_inplace_update(pg_class, tuple);
            /* the above sends a cache inval message */ }
        else
        {
             /* no need to change tuple, but force relcache inval anyway */
             CacheInvalidateRelcacheByTuple(tuple);
        }

There's a special line of comment here, and I think you wrote that part for some reason.

The reason I ask this question is that
1 similar places like the vac_update_relstats /vac_update_datfrozenxid function don't do this.
2 Local Temp table with ON COMMIT DELETE ROWS builds index for each transaction commit.
This causes relcache of the temp table to be rebuilt over and over again.

Looking forward to your reply.

Thanks


Wenjing

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

> 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