Re: About connectby() again

From: Masaru Sugawara <rk73(at)sea(dot)plala(dot)or(dot)jp>
To: Masaru Sugawara <rk73(at)sea(dot)plala(dot)or(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: About connectby() again
Date: 2002-09-26 17:27:05
Message-ID: 20020927021954.2170.RK73@sea.plala.or.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 27 Sep 2002 02:02:49 +0900
I wrote <rk73(at)sea(dot)plala(dot)or(dot)jp> wrote:

> On Sat, 07 Sep 2002 10:21:21 -0700
> Joe Conway <mail(at)joeconway(dot)com> wrote:
>
> > I just sent in a patch using the ancestor check method. It turned out
> > that the performance hit was pretty small on a moderate sized tree.
> >
> > My test case was a 220000 record bill-of-material table. The tree built
> > was 9 levels deep with about 3800 nodes. The performance hit was only
> > about 1%.
>
>
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
^^^^^^^^^^^^^^^^^^^^^^^^^
keyid or parent_keyid

> branch_delim, my image will not be perfect.
>
>
>
>
> -- test connectby with int based hierarchy
> DROP TABLE connectby_tree;
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
>
> INSERT INTO connectby_tree VALUES(11,NULL);
> INSERT INTO connectby_tree VALUES(10,11);
> INSERT INTO connectby_tree VALUES(111,11);
> INSERT INTO connectby_tree VALUES(1,111);
>
> SELECT * FROM connectby('connectby_tree', 'keyid', 'parent_keyid', '11', 0, '-')
> AS t(keyid int, parent_keyid int, level int, branch text)
>
> ERROR: infinite recursion detected
>
>
>
> Regards,
> Masaru Sugawara
>
>
>
> ---------------------------(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,
Masaru Sugawara

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Copeland 2002-09-26 17:36:57 Re: [HACKERS] Performance while loading data and indexing
Previous Message Doug cNaught 2002-09-26 17:16:36 Re: [HACKERS] Performance while loading data and indexing