Re: WITH RECURSIVE patch V0.1 - Mailing list pgsql-hackers

From Zoltan Boszormenyi
Subject Re: WITH RECURSIVE patch V0.1
Date
Msg-id 4831D378.7050201@cybertec.at
Whole thread Raw
In response to Re: WITH RECURSIVE patch V0.1  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark írta:
> "Martijn van Oosterhout" <kleptog@svana.org> writes:
>
>
>> From an implementation point of view, the only difference between
>> breadth-first and depth-first is that your tuplestore needs to be LIFO
>> instead of FIFO.
>>
>
> I think it's not so simple. How do you reconcile that concept with the join
> plans like merge join or hash join which expect you to be able to be able to
> process the records in a specific order?
>
> It sounds like you might have to keep around a stack of started executor nodes
> or something but hopefully we can avoid anything like that because, well, ick.
>

If I understand the code right, the recursion from level N to level N+1
goes like this:
collect all records from level N and JOIN it with the recursive query.
This way
we get all level 1 records from the base query, then all records at the
second level, etc.
This is how it gets breadth-first ordering.
Depth-first ordering could go like this: get only 1 from the current
level then go
into recursion. Repeat until there are no records in the current level.
The only difference would be more recursion steps. Instead of one per level,
there would be N per level if there are N tuples in the current level.
Definitely
slower then the current implementation but comparable with the tablefunc.c
connectby() code.

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: triggers on prepare, commit, rollback... ?
Next
From: cinu
Date:
Subject: Installation of Postgres 32Bit on 64 bit machine