PolarDB:Table size caching

RSC query

The RSC consists of a one-dimensional array and a hash table in shared memory.

• Each cache entry in the one-dimensional array stores the number of blocks occupied by a relation such as a table or an index.

• The hash table maps relation identifiers, known as RelFileNode values, to their corresponding cache entries in the one-dimensional array. A RelFileNode value uniquely identifies a relation at the storage layer.

All processes attempt to query the RSC by using the following two levels of indexes in sequence:

• Level 1 index: This index caches pointers to recently accessed RSC cache entries and their corresponding generation numbers. When a process requests information about a table, the level 1 index is checked first. If the requested table matches the one stored in the level 1 index and the generation number of the RSC cache entry corresponding to the pointer remains unchanged, the process can directly obtain the number of blocks occupied by the table by using the pointer. In scenarios with a high read-to-write ratio for specific tables, the level 1 index ensures a high hit ratio. If modifications occur to the mappings in the RSC hash table, the hash table must be updated, and the generation numbers of the affected RSC cache entries must be automatically incremented. This mechanism ensures that stale data in the level 1 index is invalidated.

• Level 2 index: If the level 1 index does not contain the required information, which indicates a cache miss, the process checks the level 2 index. This index queries the hash table in shared memory to obtain the RSC cache entry corresponding to the required table. Once the cache entry is located, the process obtains the number of blocks occupied by the table, and updates the level 1 index.

If the table and its corresponding block count cannot be queried in the RSC by using the preceding two levels of indexes, the cache replacement mechanism is triggered. This mechanism uses the Segmented Least Recently Used (SLRU) algorithm to select and clear a recently unused RSC cache entry. Subsequently, the lseek function of the file system is invoked to determine the actual block count. This count is then updated to the previously cleared RSC cache entry, and the two levels of indexes are synchronously updated.

RSC updates on the primary and standby nodes

After the RSC feature is enabled, any modification to the size of a table by invoking a function of the smgr requires a synchronous update to the relevant RSC cache entry in shared memory. This ensures that the cached block count of the table is the same as the actual number of blocks occupied by the table in the file system.

• When you invoke a function to extend a table, you must update the number of blocks occupied by the extended table to the RSC.

• When you invoke a function to truncate a table, you must update the number of blocks occupied by the truncated table to the RSC.

The standby nodes use physical replication to stay synchronized with the primary node. During the replay of Write Ahead Log (WAL) records, the standby nodes invoke the same functions of the smgr to modify the table size. Therefore, RSC updates are identically handled on the primary and standby nodes.

RSC updates on replica nodes

Replica nodes share physical storage with the primary node and stay synchronized with the primary node by using log indexes. Replica nodes do not perform write operations on the storage. Therefore, you cannot invoke a function of the smgr to update the RSC values in shared memory.

To determine whether file sizes have changed in the shared storage, replica nodes parse the sequence numbers of data blocks referenced in WAL records and compare the sequence numbers with the block count stored in the RSC. If a WAL record references a block sequence number higher than the cached block count, the cached block count is updated to reflect the actual block count. If a WAL record that indicates table truncation is parsed, the cached block count in the RSC is invalidated. The next time a function of the file system is invoked to obtain the number of blocks occupied by the truncated table, the RSC is repopulated with the actual block count.