8000 pgstat: stats collector references in comments. · postgrespro/postgres@bdbd3d9 · GitHub
[go: up one dir, main page]
Skip to content

Commit bdbd3d9

Browse files
anarazelanarazel
committed
pgstat: stats collector references in comments.
Soon the stats collector will be no more, with statistics instead getting stored in shared memory. There are a lot of references to the stats collector in comments. This commit replaces most of these references with "cumulative statistics system", with the remaining ones getting replaced as part of subsequent commits. This is done separately from the - quite large - shared memory statistics patch to make review easier. Author: Andres Freund <andres@anarazel.de> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de Discussion: https://postgr.es/m/20220308205351.2xcn6k4x5yivcxyd@alap3.anarazel.de
1 parent ab62a64 commit bdbd3d9
< 10000 div class="prc-PageLayout-PageLayoutContent-jzDMn">

31 files changed

+95
-107
lines changed

‎contrib/test_decoding/t/001_repl_stats.pl

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -88,8 +88,7 @@ sub test_slot_stats
8888
# Test to remove one of the replication slots and adjust
8989
# max_replication_slots accordingly to the number of slots. This leads
9090
# to a mismatch between the number of slots present in the stats file and the
91-
# number of stats present in the shared memory, simulating the scenario for
92-
# drop slot message lost by the statistics collector process. We verify
91+
# number of stats present in shared memory. We verify
9392
# replication statistics data is fine after restart.
9493

9594
$node->stop;

‎src/backend/access/heap/heapam_handler.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1089,8 +1089,8 @@ heapam_scan_analyze_next_tuple(TableScanDesc scan, TransactionId OldestXmin,
10891089
* our own. In this case we should count and sample the row,
10901090
* to accommodate users who load a table and analyze it in one
10911091
* transaction. (pgstat_report_analyze has to adjust the
1092-
* numbers we send to the stats collector to make this come
1093-
* out right.)
1092+
* numbers we report to the cumulative stats system to make
1093+
* this come out right.)
10941094
*/
10951095
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(targtuple->t_data)))
10961096
{

‎src/backend/access/heap/vacuumlazy.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -609,9 +609,9 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
609609
&frozenxid_updated, &minmulti_updated, false);
610610

611611
/*
612-
* Report results to the stats collector, too.
612+
* Report results to the cumulative stats system, too.
613613
*
614-
* Deliberately avoid telling the stats collector about LP_DEAD items that
614+
* Deliberately avoid telling the stats system about LP_DEAD items that
615615
* remain in the table due to VACUUM bypassing index and heap vacuuming.
616616
* ANALYZE will consider the remaining LP_DEAD items to be dead "tuples".
617617
* It seems like a good idea to err on the side of not vacuuming again too
@@ -2228,10 +2228,10 @@ lazy_vacuum(LVRelState *vacrel)
22282228
* dead_items space is not CPU cache resident.
22292229
*
22302230
* We don't take any special steps to remember the LP_DEAD items (such
2231-
* as counting them in our final report to the stats collector) when
2231+
* as counting them in our final update to the stats system) when
22322232
* the optimization is applied. Though the accounting used in
22332233
* analyze.c's acquire_sample_rows() will recognize the same LP_DEAD
2234-
* items as dead rows in its own stats collector report, that's okay.
2234+
* items as dead rows in its own stats report, that's okay.
22352235
* The discrepancy should be negligible. If this optimization is ever
22362236
* expanded to cover more cases then this may need to be reconsidered.
22372237
*/

‎src/backend/commands/analyze.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -680,7 +680,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
680680
}
681681

682682
/*
683-
* Now report ANALYZE to the stats collector. For regular tables, we do
683+
* Now report ANALYZE to the cumulative stats system. For regular tables, we do
684684
* it only if not doing inherited stats. For partitioned tables, we only
685685
* do it for inherited stats. (We're never called for not-inherited stats
686686
* on partitioned tables anyway.)

‎src/backend/commands/dbcommands.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1665,7 +1665,7 @@ dropdb(const char *dbname, bool missing_ok, bool force)
16651665
DropDatabaseBuffers(db_id);
16661666

16671667
/*
1668-
* Tell the stats collector to forget it immediately, too.
1668+
* Tell the cumulative stats system to forget it immediately, too.
16691669
*/
16701670
pgstat_drop_database(db_id);
16711671

‎src/backend/commands/matview.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -338,10 +338,10 @@ ExecRefreshMatView(RefreshMatViewStmt *stmt, const char *queryString,
338338
refresh_by_heap_swap(matviewOid, OIDNewHeap, relpersistence);
339339

340340
/*
341-
* Inform stats collector about our activity: basically, we truncated
342-
* the matview and inserted some new data. (The concurrent code path
343-
* above doesn't need to worry about this because the inserts and
344-
* deletes it issues get counted by lower-level code.)
341+
* Inform cumulative stats system about our activity: basically, we
342+
* truncated the matview and inserted some new data. (The concurrent
343+
* code path above doesn't need to worry about this because the inserts
344+
* and deletes it issues get counted by lower-level code.)
345345
*/
346346
pgstat_count_truncate(matviewRel);
347347
if (!stmt->skipData)

‎src/backend/commands/subscriptioncmds.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1409,7 +1409,7 @@ DropSubscription(DropSubscriptionStmt *stmt, bool isTopLevel)
14091409
* slot stays dropped even if the transaction rolls back. So we cannot
14101410
* run DROP SUBSCRIPTION inside a transaction block if dropping the
14111411
* replication slot. Also, in this case, we report a message for dropping
1412-
* the subscription to the stats collector.
1412+
* the subscription to the cumulative stats system.
14131413
*
14141414
* XXX The command name should really be something like "DROP SUBSCRIPTION
14151415
* of a subscription that is associated with a replication slot", but we
@@ -1583,7 +1583,7 @@ DropSubscription(DropSubscriptionStmt *stmt, bool isTopLevel)
15831583
PG_END_TRY();
15841584

15851585
/*
1586-
* Send a message for dropping this subscription to the stats collector.
1586+
* Tell the cumulative stats system that the subscription is getting dropped.
15871587
* We can safely report dropping the subscription statistics here if the
15881588
* subscription is associated with a replication slot since we cannot run
15891589
* DROP SUBSCRIPTION inside a transaction block. Subscription statistics

‎src/backend/commands/vacuum.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -352,8 +352,8 @@ vacuum(List *relations, VacuumParams *params,
352352
errmsg("PROCESS_TOAST required with VACUUM FULL")));
353353

354354
/*
355-
* Send info about dead objects to the statistics collector, unless we are
356-
* in autovacuum --- autovacuum.c does this for itself.
355+
* Send info about dead objects to the cumulative stats system, unless
356+
* we are in autovacuum --- autovacuum.c does this for itself.
357357
*/
358358
if ((params->options & VACOPT_VACUUM) && !IsAutoVacuumWorkerProcess())
359359
pgstat_vacuum_stat();

‎src/backend/postmaster/autovacuum.c

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1689,7 +1689,7 @@ AutoVacWorkerMain(int argc, char *argv[])
16891689
char dbname[NAMEDATALEN];
16901690

16911691
/*
1692-
* Report autovac startup to the stats collector. We deliberately do
1692+
* Report autovac startup to the cumulative stats system. We deliberately do
16931693
* this before InitPostgres, so that the last_autovac_time will get
16941694
* updated even if the connection attempt fails. This is to prevent
16951695
* autovac from getting "stuck" repeatedly selecting an unopenable
@@ -1996,9 +1996,9 @@ do_autovacuum(void)
19961996
StartTransactionCommand();
19971997

19981998
/*
1999-
* Clean up any dead statistics collector entries for this DB. We always
2000-
* want to do this exactly once per DB-processing cycle, even if we find
2001-
* nothing worth vacuuming in the database.
1999+
* Clean up any dead statistics entries for this DB. We always want to do
2000+
* this exactly once per DB-processing cycle, even if we find nothing
2001+
* worth vacuuming in the database.
20022002
*/
20032003
pgstat_vacuum_stat();
20042004

@@ -3041,7 +3041,7 @@ recheck_relation_needs_vacanalyze(Oid relid,
30413041
*
30423042
* For analyze, the analysis done is that the number of tuples inserted,
30433043
* deleted and updated since the last analyze exceeds a threshold calculated
3044-
* in the same fashion as above. Note that the collector actually stores
3044+
* in the same fashion as above. Note that the cumulative stats system stores
30453045
* the number of tuples (both live and dead) that there were as of the last
30463046
* analyze. This is asymmetric to the VACUUM case.
30473047
*
@@ -3051,8 +3051,8 @@ recheck_relation_needs_vacanalyze(Oid relid,
30513051
*
30523052
* A table whose autovacuum_enabled option is false is
30533053
* automatically skipped (unless we have to vacuum it due to freeze_max_age).
3054-
* Thus autovacuum can be disabled for specific tables. Also, when the stats
3055-
* collector does not have data about a table, it will be skipped.
3054+
* Thus autovacuum can be disabled for specific tables. Also, when the cumulative
3055+
* stats system does not have data about a table, it will be skipped.
30563056
*
30573057
* A table whose vac_base_thresh value is < 0 takes the base value from the
30583058
* autovacuum_vacuum_threshold GUC variable. Similarly, a vac_scale_factor

‎src/backend/postmaster/bgwriter.c

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -240,9 +240,7 @@ BackgroundWriterMain(void)
240240
*/
241241
can_hibernate = BgBufferSync(&wb_context);
242242

243-
/*
244-
* Send off activity statistics to the stats collector
245-
*/
243+
/* Report pending statistics to the cumulative stats system */
246244
pgstat_send_bgwriter();
247245

248246
if (FirstCallSinceLastCheckpoint())

0 commit comments

Comments
 (0)
0