Re: [PATCH]: Not to invaldiate CatalogSnapshot for local invalidation messages

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 <fanfuxiaoran(at)gmail(dot)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
>