Re: CONNECT BY PRIOR

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Yann Michel <yann-postgresql(at)spline(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CONNECT BY PRIOR
Date: 2005-11-15 08:53:41
Message-ID: 20051115085340.GA7519@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2005 at 01:38:31AM -0500, Jonah H. Harris wrote:
> Hey Simon,
> I'm doing some research into recursive query planning in terms of theory
> as-well-as actual implementation in other RDBMS. Let me get back to you when
> I have some more definitive info.

My first reaction would be to have a sort of Repeat node, with two
subnodes, the Tail and the Loop. The procedure would be to extract a
tuple from the Tail (optionally returning it). Then put that tuple
as the input to the Loop and start pulling tuples out of that.

Problem is, those new tuples may have to be sent through the loop again
so you have a buffering problem. But it seems a fairly generic way of
dealing with it.

Ofcourse, once you've done that, you might be getting very close to a
Turing complete executor, no? :)

Have a nice day,

> On 11/14/05, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > On Sat, 2005-11-12 at 15:27 -0500, Jonah H. Harris wrote:
> >
> > > I am working on the standard WITH syntax for recursive query support
> > > and hope to get it into 8.2.
> >
> > Sounds interesting.
> >
> > What approach are you taking to the plan shape? The current approach
> > would be to have additional plan nodes for each join. Coping with a
> > dynamic number of operations will do interesting things in the planner.
> >
> > I face a similar dynamic problem with joins to partitioned tables.
> >
> > Do you have any thoughts about this area?
> >
> > Best Regards, Simon Riggs
> >
> >
> >

--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message eric.leguillier 2005-11-15 08:58:14 Re: Running PostGre on DVD
Previous Message Magnus Hagander 2005-11-15 08:48:25 Re: Fixes for 8.1 run of pgindent