(cloudberry) 05/16: Avoid syncscan for vacuum full and cluster for catalog tables

[ma...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

maxyang pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/cloudberry.git

commit ed99c71940275925c2ed57362da3ddccf43261e1
Author: Ashwin Agrawal <aa...@vmware.com>
AuthorDate: Fri Mar 3 16:39:47 2023 -0800

    Avoid syncscan for vacuum full and cluster for catalog tables
    
    Backends load or build relcache when starting (process title conveys
    "startup"). If relcache init file is present then can just load
    relcache from it. In absence of the file (file is deleted on sinval
    message), need to perform sequential scan on pg_class, pg_attribute
    for locating tuples related to these critical system tables and
    indexes to build the relcache, refer RelationCacheInitializePhase3().
    
    General expectation is tuples corresponding to these critical catalog
    tables (created during bootstrap and with xmin=1) will be present in
    starting blocks and hence seqscan and tuple visibility will not be
    costly to perform during backend startup. Though occassionally in
    production setups these bootstrap tuples were found in very high block
    numbers for pg_attribute. As a effect from this, backends stalled for
    very long time in startup phase, specially if tuple visibility gets
    costly due to presence of subtransaction overflow or long running
    transaction. VACUUM FULL was traced as the culprit for moving these
    tuples from starting blocks to very high block numbers.
    
    VACUUM FULL used syncscan during rewrite. Effect of that is scans the
    table circularly, from block X up to the end and then from block 0 to
    X-1. If X != 0, then all the tuples from block 0 end up last in new
    file (higher block numbers). Hence disabling to use syncscan for
    vacuum full and cluster operations to avoid movement of these critical
    tuples from starting block numbers.
    
    Refer:
    https://www.postgresql.org/message-id/flat/CAKSySwf%2BYH_4%3DUDosdyNG2%2BEYOFaThsATB9AfNkUjM4uq%2B69vQ%40mail.gmail.com
    
    Also fixes https://github.com/greenplum-db/gpdb/issues/13453.
    
    Reviewed-by: Huansong Fu <fu...@gmail.com>
---
 src/backend/access/heap/heapam_handler.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 2537fc9ea5..6ed3ad07b3 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -778,7 +778,18 @@ heapam_relation_copy_for_cluster(Relation OldHeap, Relation NewHeap,
 		pgstat_progress_update_param(PROGRESS_CLUSTER_PHASE,
 									 PROGRESS_CLUSTER_PHASE_SEQ_SCAN_HEAP);
 
-		tableScan = table_beginscan(OldHeap, SnapshotAny, 0, (ScanKey) NULL);
+		/*
+		 * For Catalog tables avoid syncscan, so that scan always starts from
+		 * block 0 during rewrite and helps retain bootstrap tuples in initial
+		 * pages only. If using syncscan, then bootstrap tuples may move to
+		 * higher blocks, which will lead to degraded performance for relcache
+		 * initialization during connection starts.
+		*/
+		if (IsCatalogRelation(OldHeap))
+			tableScan = table_beginscan_strat(OldHeap,
+											  SnapshotAny, 0, (ScanKey) NULL, true, false);
+		else
+			tableScan = table_beginscan(OldHeap, SnapshotAny, 0, (ScanKey) NULL);
 		heapScan = (HeapScanDesc) tableScan;
 		indexScan = NULL;
 


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: commits-help@cloudberry.apache.org