mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove obsolete comment block in nbtsort.c.

Browse Source 
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
This commit is contained in:
Peter Geoghegan 2018-06-26 10:08:44 -07:00
parent 040da42367
commit cdc2693a11
1 changed files with 0 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/access/nbtree/nbtsort.c
View File

@ -14,15 +14,6 @@
* its parent level. When we have only one page on a level, it must be * 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. * 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* * 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 * 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 * for a split would cascade right up the tree). The steady-state load