Hi hackers, I would like to give more details of my patch.
In postgres, it uses a global snapshot “CatalogSnapshot” to check catalog data visibility. “CatalogSnapshot” is always updated to the latest version to make the latest catalog table content visible. If there is any updating on catalog tables, to make the changes to be visible for the following commands in the current transaction, “CommandCounterIncrement”- >”AtCCI_LocalCache” ->”CommandEndInvalidationMessages ”->”LocalExecuteInvalidationMessage” ->”InvalidateCatalogSnapshot” it will invalidate the “CatalogSnapshot” by setting it to NULL. And next time, when it needs the “CatalogSnapsthot” and finds it is NULL, it will regenerate one. In a query, “CommandCounterIncrement” may be called many times, and “CatalogSnapsthot” may be destroyed and recreated many times. To reduce such overhead, instead of invalidating “CatalogSnapshot” , we can keep it and just increase the “curcid” of it. When the transaction is committed or aborted, or there are catalog invalidation messages from other backends, the “CatalogSnapshot” will be invalidated and regenerated. Sometimes, the “CatalogSnapshot” is not the same as the transaction “CurrentSnapshot”, but we can still update the CatalogSnapshot’s “curcid”, as the “curcid” only be checked when the tuple is inserted or deleted by the current transaction. Xiaoran Wang <fanfuxiao...@gmail.com> 于2023年12月7日周四 10:13写道： > Hi hackers, > > > For local invalidation messages, there is no need to call > `InvalidateCatalogSnapshot` to set the CatalogSnapshot to NULL and > rebuild it later. Instead, just update the CatalogSnapshot's `curcid` > in `SnapshotSetCommandId`, this way can make the CatalogSnapshot work > well too. > > This optimization can reduce the overhead of rebuilding CatalogSnapshot > after each command. > > > Best regards, xiaoran >
