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
