Re: recursing down a tree

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: --CELKO-- <71062(dot)1056(at)compuserve(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: recursing down a tree
Date: 2002-07-15 13:39:08
Message-ID: Pine.GSO.4.44.0207151632170.15324-100000@ra.sai.msu.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 12 Jul 2002, --CELKO-- wrote:

> >> I did a little research on the subject and it seemed quite
> interesting. However, it seemed that insertion would require updating
> most of the tree for
> a minor insert. Can you send along a few more details about your setup
> and algorithms? I would like to find more information about this. <<
>
> I am writing a separate book on "Trees in SQL" which will cover
> several different models; I hope to be done by the end of the year. I
> also hope to win the lottery.

Cool. btw, we have developed contrib/tree module which is very fast
for r/o operations. It's available on our GiST development page
http://www.sai.msu.su/~megera/postgres/gist/tree/README.tree.english
The idea is simple - to code path information to the node name,
so tuple itself does know it's place in hierarchy. It's sort of
cheating of relational data model. Also, we're developing another
module - contrib/ltree which will be much more powerful (we use
real names in path instead of digits as in contrib/tree).

>
> Updating is not the problem people think it is. The nodes are in one
> table and the structure is in another. The Tree table has (node_id,
> lft, rgt) in its rows and those the rows are very short; a lot of them
> fit into main storage at once. Since the newest addition (i.e.
> youngest sibling) is made on the right side of the immediate
> subordinates (siblings are ordered in the Nested Set model), you do
> not have to update half the nodes on average. Finally, in the real
> world, the tree structure tends to stay the same and the nodes change
> -- even dot-com firms don't re-organize faster than their personnel
> turnover <g>.
>
> However, someone did have a situation where they used the nested set
> model for the message threads in a newsgroup front end. Their answer
> to this "fixed nodes and changing structure" problem was to use large
> gaps in the numbering of (lft, rgt) pairs instead of incrementing
> (lft, rgt) by one.
>
> Think about it; subordination is shown with the BETWEEN predicate; any
> sequence of unique, nested numbers will work. Subtree size is shown
> by the formula ((rgt-lft+1)/2) which does depend on an increment and
> happens to also give you subordination.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian 'Dagurashibanipal' von Bidder 2002-07-15 13:47:28 Re: SERIAL behaviour
Previous Message Curt Sampson 2002-07-15 13:30:25 Re: SERIAL behaviour