From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Greg Stark <stark(at)enterprisedb(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CYCLE and SEARCH [was Re: Common Table Expressions (WITH RECURSIVE) patch] |
Date: | 2008-10-05 15:41:21 |
Message-ID: | 2785.1223221281@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> How hard would it be to add the infrastructure for CYCLE?
Personally I'm more interested in getting the recursive UNION (without
ALL) case to work.
I think that this might just be a matter of drawing on support that's
already there: have RecursiveUnion maintain a hash table of rows it's
already seen, and discard anything coming from either the non-recursive
term or the recursive term that is found to be already present in the
hash table.
Two objections to this are (a) it doesn't work for datatypes without
hash equality support, and (b) it would fail for recursion output
exceeding available memory. However, the alternative of using
sort-and-uniq to detect duplicates seems pretty horrid in this situation
--- you'd need a fresh sort and mergejoin-like scan for every iteration
of the recursive term. And it would become impractical to return rows
immediately after they're emitted by the subqueries. So I'd be willing
to live with only supporting the hash implementation.
If no objections, I'll look at that next week ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-05 16:33:18 | new int8 test still has problems |
Previous Message | Tom Lane | 2008-10-05 15:19:33 | Re: Common Table Expressions applied; some issues remain |