Re: contrib/tree

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib/tree
Date: 2002-01-27 11:31:34
Message-ID: 1012131094.9785.0.camel@rh72.home.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2002-01-27 at 06:06, Don Baccus wrote:
> Hannu Krosing wrote:
>
>
> > I'll try if I can build the operators in PL/PGSL so one would not
> > "really" need to build special operators ;)

Ok, I've done most of it (the comparison functions and operators), but
now I'm stuck with inability to find any arrayconstructing functionality
in postgres - the only way seems to be the text-to-type functions .

Also arrays seem to be read only -- a[i] := 1 is a syntax error.

And get/set slice operators are defined static in source ;(

> > Tell me if this is something impossible.
>
>
> There's the speed issue, of course ... and the extra space, which for
> deep trees could be significant.
>
> Our solution suits our needs very well, and we're happy with it. We do
> get 2 billion plus immediate children per node and a one-byte per level
> key for trees that aren't big and flat. The intarray approach is just a
> different storage technique for the same method, I don't see that moving
> nodes is any easier (you have to touch the same number of nodes if you
> move a subtree around).

Is there a simple query for getting all ancestors of a node ?

The intarray approach has all them already encoded .

> It takes more storage and the necessary
> comparisons (even if written in C) will be slower unless the tree's big
> and flat (because you're using four bytes for every level, while our BIT
> VARYING scheme, in practice, uses one byte for each level in a very
> large majority of cases).

I'm inclining more and more towards using your approach. I just even
figured out that I don't rreally need to get the ancestors for my needs.

-------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gunaseelan Nagarajan 2002-01-27 14:22:58 Re: Bad Timestamp Format
Previous Message Marc G. Fournier 2002-01-27 07:14:11 Re: [HACKERS] PostgreSQL v7.2rc2 Released