mirror of
https://github.com/postgres/postgres.git
synced 2025-04-27 22:56:53 +03:00
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
This commit is contained in:
parent
040da42367
commit
cdc2693a11
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user