- Notifications
You must be signed in to change notification settings - Fork28
Commit3a675f7
committed
Count heap tuples in non-SnapshotAny path in IndexBuildHeapRangeScan().
Brown-paper-bag bug in commit7c91a03: when we rearranged the placementof "reltuples += 1" statements, we missed including one in this code path.The net effect of that was that CREATE INDEX CONCURRENTLY would set thetable's pg_class.reltuples to zero, as would index builds done duringbootstrap mode. (It seems like parallel index builds ought to failsimilarly, but they don't, perhaps because reltuples is computed in someother way. You certainly couldn't figure that out from the abysmallyunderdocumented parallelism code in this area.)I was led to this by wondering why initdb seemed to have slowed down asa result of7c91a03, 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 forqueries in the post-bootstrap steps. On my workstation, this fix causesthe runtime of "initdb -N" to drop from ~2.0 sec to ~1.4 sec, which isalmost though not quite back to where it was in v10. That's not much ofa deal for production use perhaps, but it makes a noticeable differencefor buildfarm and "make check-world" runs, which do a lot of initdbs.1 parentd2c1512 commit3a675f7
1 file changed
+1
-0
lines changedLines changed: 1 addition & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2850 | 2850 | | |
2851 | 2851 | | |
2852 | 2852 | | |
| 2853 | + | |
2853 | 2854 | | |
2854 | 2855 | | |
2855 | 2856 | | |
| |||
0 commit comments
Comments
(0)