From 2a77b947e07dadef953019334062580cad560836 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Sun, 24 Jun 2018 11:41:16 -0700 Subject: [PATCH] Remove obsolete comment block in nbtsort.c. Building a new index through incremental nbtree insertions would always be significantly slower than our actual approach of sorting using tuplesort, and then building and WAL-logging whole pages. Remove a comment block from the Berkeley days claiming that incremental insertions might be slightly faster with presorted input. --- src/backend/access/nbtree/nbtsort.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/src/backend/access/nbtree/nbtsort.c b/src/backend/access/nbtree/nbtsort.c index e012df596e..16f5755777 100644 --- a/src/backend/access/nbtree/nbtsort.c +++ b/src/backend/access/nbtree/nbtsort.c @@ -14,15 +14,6 @@ * its parent level. When we have only one page on a level, it must be * the root -- it can be attached to the btree metapage and we are done. * - * This code is moderately slow (~10% slower) compared to the regular - * btree (insertion) build code on sorted or well-clustered data. On - * random data, however, the insertion build code is unusable -- the - * difference on a 60MB heap is a factor of 15 because the random - * probes into the btree thrash the buffer pool. (NOTE: the above - * "10%" estimate is probably obsolete, since it refers to an old and - * not very good external sort implementation that used to exist in - * this module. tuplesort.c is almost certainly faster.) - * * It is not wise to pack the pages entirely full, since then *any* * insertion would cause a split (and not only of the leaf page; the need * for a split would cascade right up the tree). The steady-state load -- 2.17.1