Re: Common Table Expressions (WITH RECURSIVE) patch

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql(at)j-davis(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Date: 2008-09-21 02:42:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> PlanState.has_recursivescan seems like a complete kluge. Can't it just be
> removed? It looks to me like it is working around bugs that hopefully aren't
> there anymore. There is certainly no reason why a recursive CTE should be
> more in need of rescanning than any other kind of plan.

I don't think so. Recursion plan needs the hash table used by sublan
be re-created at each recursion loop stage. Remember that in each
evaluation of recursive plan, the recursive name is replaced by a
working table which is holding previous evalution result of recursion
stage. Thus the hash table corresponding to the work table needs to
be re-created.

> If it is needed then
> the current implementation is completely broken anyway, since it would only
> detect a RecursiveScan node that is directly underneath an agg or hash node.

Yeah, that's right. What I have in my mind is to implement something
similar to UpdateChangedParamSet family like mechanism which will
inherit working table change event to child node.
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-21 02:52:09 Re: Common Table Expressions (WITH RECURSIVE) patch
Previous Message Tom Lane 2008-09-21 02:09:10 Re: [patch] fix dblink security hole