Re: contrib/tree

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