From 3a675f729ea96c8bf3e764996a0c743500e564ef Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 8 May 2018 00:20:19 -0400 Subject: [PATCH] Count heap tuples in non-SnapshotAny path in IndexBuildHeapRangeScan(). Brown-paper-bag bug in commit 7c91a0364: when we rearranged the placement of "reltuples += 1" statements, we missed including one in this code path. The net effect of that was that CREATE INDEX CONCURRENTLY would set the table's pg_class.reltuples to zero, as would index builds done during bootstrap mode. (It seems like parallel index builds ought to fail similarly, but they don't, perhaps because reltuples is computed in some other way. You certainly couldn't figure that out from the abysmally underdocumented parallelism code in this area.) I was led to this by wondering why initdb seemed to have slowed down as a result of 7c91a0364, as is evident in the buildfarm's timing history. The reason is that every system catalog with indexes had pg_class.reltuples = 0 after bootstrap, causing the planner to make some terrible choices for queries in the post-bootstrap steps. On my workstation, this fix causes the runtime of "initdb -N" to drop from ~2.0 sec to ~1.4 sec, which is almost though not quite back to where it was in v10. That's not much of a deal for production use perhaps, but it makes a noticeable difference for buildfarm and "make check-world" runs, which do a lot of initdbs. --- src/backend/catalog/index.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index 6c40b29b3f..8b276bc430 100644 --- a/src/backend/catalog/index.c +++ b/src/backend/catalog/index.c @@ -2850,6 +2850,7 @@ IndexBuildHeapRangeScan(Relation heapRelation, { /* heap_getnext did the time qual check */ tupleIsAlive = true; + reltuples += 1; } MemoryContextReset(econtext->ecxt_per_tuple_memory); -- 2.40.0