Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 3 commits
- 14 files changed
- 2 contributors
Commits on Dec 27, 2025
-
Key PGSTAT_KIND_RELATION by relfile locator
This patch changes the key used for the PGSTAT_KIND_RELATION statistic kind. Instead of the relation oid, it now relies on: - dboid (linked to RelFileLocator's dbOid) - objoid which is the result of a new macro (namely RelFileLocatorToPgStatObjid()) that computes an objoid based on the RelFileLocator's spcOid and the RelFileLocator's relNumber. This is possible as, since b14e9ce, the objoid is now uint64 and spcOid and relNumber are 32 bits. That will allow us to add new stats (add writes counters) and ensure that some counters (n_dead_tup and friends) are replicated. The patch introduces pgstat_reloid_to_relfilelocator() to 1) avoid calling RelationIdGetRelation() to get the relfilelocator based on the relation oid and 2) handle the partitioned table case. Please note that: - when running pg_stat_have_stats('relation',...) we now need to be connected to the database that hosts the relation. As pg_stat_have_stats() is not documented publicly, then the changes done in 029_stats_restart.pl look enough. - this patch does not handle rewrites so some tests are failing. It's only intent is to ease the review and should not be pushed without being merged with the following patch that handles the rewrites. - it can be used to test that stats are incremented correctly and that we're able to retrieve them as long as rewrites are not involved.
-
handle relation statistics correctly during rewrites
Now that PGSTAT_KIND_RELATION is keyed by refilenode, we need to handle rewrites. To do so, this patch: - Adds PgStat_PendingRewrite, a new struct to track rewrite operations within a transaction, storing the old locator, new locator, and original locator (for rewrite chains). This allows stats to be copied from the original location to the final location at commit time. - Adds a new function, pgstat_mark_rewrite(), called when a table rewrite begins. It records the rewrite operation in a local list and detects rewrite chains by checking if the old_locator matches any existing new_locator, preserving the chain's original_locator. - Modifies pgstat_copy_relation_stats(), to accept RelFileLocators instead of Relations, with a new increment parameter to accumulate stats (needed for rewrite chains with DML between rewrites). - Ensures that AtEOXact_PgStat_Relations(), AtPrepare_PgStat_Relations(), pgstat_twophase_postcommit()/postabort() pgstat_drop_relation() handle the PgStat_PendingRewrite list correctly. Note that due to the new flush call in pgstat_twophase_postcommit() we can not call GetCurrentTransactionStopTimestamp() in pgstat_relation_flush_cb(). So, adding a check to handle this special case and call GetCurrentTimestamp() instead. Note that we'd call GetCurrentTimestamp() only if there is a rewrite, so that the GetCurrentTimestamp() extra cost should be negligible. Another solution could be to trigger the flush from FinishPreparedTransaction() but that's not worth the extra complexity. The new pending_rewrites list is traversed in multiple places. The overhead should be negligible in comparison to a rewrite and the list should not contain a lot of rewrites in practice. The pending_rewrites list is traversed in multiple places. In typical usage, the list will contain only a few entries so the traversal cost is negligible ( furthermore in comparison to a rewrite).
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff cf/5007~1...cf/5007