postgres.git / summary / log / commit / refs

commit    cdc2693a11b341043f33e1efc36debe0348fb361
Author:   Peter Geoghegan <pg@bowt.ie>
Date:     Tue Jun 26 17:08:44 2018 +0000
First released in: 11.0

    Remove obsolete comment block in nbtsort.c.
    
    Building a new nbtree index through incremental insertions would always
    be slower than our actual approach of sorting using tuplesort,
    assembling leaf pages from tuplesort output, and writing and WAL-logging
    whole pages.  Remove a comment block from the Berkeley days claiming
    that incremental insertions might be slightly faster with presorted
    input.
    
    Discussion: https://postgr.es/m/CAH2-WzmKs4mLAoFgJ3yHMRYc849efc=dw+pNRb3NEog2oJoCNw@mail.gmail.com


 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 e012df596ed..16f57557776 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


[parent: 040da42367a5]