Re: [CFReview] Red-Black Tree

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [CFReview] Red-Black Tree
Date: 2010-02-06 06:21:29
Message-ID: 603c8f071002052221y244802aawd739ebca90e54d28@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/2/4 Teodor Sigaev <teodor(at)sigaev(dot)ru>:
> Oleg's test (http://www.sai.msu.su/~megera/wiki/rbtree_test) are made with
> v0.10 which is differ from 0.11 only by comments around ginInsertRecordBA()

That looks pretty good. I confess I don't fully understand why it
works. If we're inserting a bunch of equal-key entries, why does it
matter what order we insert them in? Is there some code in here
(where?) that breaks ties on the basis of where they are in the input
data?

I think that the code in ginInsertRecordBA() is needlessly complex.
As far as I can see, nNodesOnCurrentLevel is always exactly one more
than nNodesOnPreviousLevel, and I think step is also basically
redundant with both of these although the relationship is a little
more complex. What I would suggest is something like:

- initialize step to the largest power of 2 s.t. step < nentry
- while step > 0
-- for (i = step; true; i += 2 * step)
--- insert entry #i-1
--- if i > nentry - (2 * step) /* must test before incrementing i, to
guard against overflow */
---- break
-- step = step / 2

Typos:

bunary -> binary
This insertion order decreases number of rebalancing for tree ->
should be "number of rebalancings"
castomized -> customized

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-02-06 11:58:05 Re: archive_timeout behavior for no activity
Previous Message Tom Lane 2010-02-06 06:20:53 Re: Reading deleted records - PageHeader v3