From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Tatsuo Ishii" <ishii(at)sraoss(dot)co(dot)jp>, ishii(at)postgresql(dot)org, pgsql(at)j-davis(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Common Table Expressions (WITH RECURSIVE) patch |
Date: | 2008-09-09 20:07:22 |
Message-ID: | 24326.1220990842@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>> I am blind, I didn't find any reason, why materialisation isn't useable.
> I believe it's because of these two (closely related) problems:
> # The basic
> # implementation clearly ought to be to dump the result of the subquery
> # into a tuplestore and then have the upper level read out from that.
> # However, we don't have any infrastructure for having multiple
> # upper-level RTEs reference the same tuplestore. (Perhaps the InitPlan
> # infrastructure could be enhanced in that direction, but it's not ready
> # for non-scalar outputs today.) Also, I think we'd have to teach
> # tuplestore how to support multiple readout cursors. For example,
> # consider
> # WITH foo AS (SELECT ...) SELECT ... FROM foo a, foo b WHERE ...
> # If the planner chooses to do the join as a nested loop then each
> # Scan node needs to keep track of its own place in the tuplestore,
> # concurrently with the other node having a different place.
The amount of new code needed for that seems a pittance compared to the
size of the patch already, so I'm not seeing why Tatsuo-san considers
it infeasible.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | daveg | 2008-09-09 20:08:25 | Re: Keeping creation time of objects |
Previous Message | Hannu Krosing | 2008-09-09 20:03:56 | Re: Keeping creation time of objects |