Prevent synchronized scanning when systable_beginscan chooses a heapscan.

tglsfdc · tglsfdc · commit 2ce097e6e898 · 2012-05-26T19:10:05.000-04:00
The only interesting-for-performance case wherein we force heapscan here
is when we're rebuilding the relcache init file, and the only such case
that is likely to be examining a catalog big enough to be syncscanned is
RelationBuildTupleDesc.  But the early-exit optimization in that code gets
broken if we start the scan at a random place within the catalog, so that
allowing syncscan is actually a big deoptimization if pg_attribute is large
(at least for the normal case where the rows for core system catalogs have
never been changed since initdb).  Hence, prevent syncscan here.  Per my
testing pursuant to complaints from Jeff Frost and Greg Sabino Mullane,
though neither of them seem to have actually hit this specific problem.

Back-patch to 8.3, where syncscan was introduced.
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
@@ -291,7 +291,16 @@ systable_beginscan(Relation heapRelation,
 	}
 	else
 	{
-		sysscan->scan = heap_beginscan(heapRelation, snapshot, nkeys, key);
+		/*
+		 * We disallow synchronized scans when forced to use a heapscan on a
+		 * catalog.  In most cases the desired rows are near the front, so
+		 * that the unpredictable start point of a syncscan is a serious
+		 * disadvantage; and there are no compensating advantages, because
+		 * it's unlikely that such scans will occur in parallel.
+		 */
+		sysscan->scan = heap_beginscan_strat(heapRelation, snapshot,
+											 nkeys, key,
+											 true, false);
 		sysscan->iscan = NULL;
 	}
 

Original file line number	Diff line number	Diff line change
`@@ -291,7 +291,16 @@ systable_beginscan(Relation heapRelation,`
`291`	`291`	`}`
`292`	`292`	`else`
`293`	`293`	`{`
`294`		`- sysscan->scan = heap_beginscan(heapRelation, snapshot, nkeys, key);`
	`294`	`+ /*`
	`295`	`+ * We disallow synchronized scans when forced to use a heapscan on a`
	`296`	`+ * catalog. In most cases the desired rows are near the front, so`
	`297`	`+ * that the unpredictable start point of a syncscan is a serious`
	`298`	`+ * disadvantage; and there are no compensating advantages, because`
	`299`	`+ * it's unlikely that such scans will occur in parallel.`
	`300`	`+ */`
	`301`	`+ sysscan->scan = heap_beginscan_strat(heapRelation, snapshot,`
	`302`	`+ nkeys, key,`
	`303`	`+ true, false);`
`295`	`304`	`sysscan->iscan = NULL;`
`296`	`305`	`}`
`297`	`306`