Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit cdc2693

Browse files
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
1 parent 040da42 commit cdc2693

File tree

1 file changed

+0
-9
lines changed

1 file changed

+0
-9
lines changed

src/backend/access/nbtree/nbtsort.c

-9
Original file line numberDiff line numberDiff line change
@@ -14,15 +14,6 @@
1414
* its parent level. When we have only one page on a level, it must be
1515
* the root -- it can be attached to the btree metapage and we are done.
1616
*
17-
* This code is moderately slow (~10% slower) compared to the regular
18-
* btree (insertion) build code on sorted or well-clustered data. On
19-
* random data, however, the insertion build code is unusable -- the
20-
* difference on a 60MB heap is a factor of 15 because the random
21-
* probes into the btree thrash the buffer pool. (NOTE: the above
22-
* "10%" estimate is probably obsolete, since it refers to an old and
23-
* not very good external sort implementation that used to exist in
24-
* this module. tuplesort.c is almost certainly faster.)
25-
*
2617
* It is not wise to pack the pages entirely full, since then *any*
2718
* insertion would cause a split (and not only of the leaf page; the need
2819
* for a split would cascade right up the tree). The steady-state load

0 commit comments

Comments
 (0)