On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
> 2010/7/17 Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>:
> > On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
> >>
> >> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
> >> is exsiting one that work with single tuplestore, it might be sane to
> >> modify this so that it accepts tuplestore from Query instead of its
> >> child node.
> >
> > I thought about this, but I don't necessarily like the idea of overloading
> > executor nodes.
>
> Neither do I have good shape for this solution. Maybe it's not good
> idea. But my concern is adding DtScanNode, which looks similar to
> MaterialNode. Of course each purpose is different, but quite big part
> will overlap each other, I think.
Any ideas as to how to factor this out? Handiest ideas would be in
the form of a patch ;)
> >> 2. Use temp table instead of tuplestore list. Since we agreed we need
> >> to execute each plan one by one starting and shutting down executor,
> >> it now looks very simple strategy.
> >
> > I didn't look at this because I thought using a "tuplestore receiver" in the
> > portal logic was simple enough. Any thoughts on how this would work?
>
> It's just deconstructing queries like:
>
> WITH t AS (INSERT INTO x ... RETURING *)
> SELECT * FROM t;
>
> to
>
> CREATE TEMP TABLE t AS INSERT INTO x ... RETURING *;
> SELECT * FROM t;
>
> While the second statement is not implemented yet, it will be so simpler.
So CTAS would get expanded into CTA[row-returning query] ?
Interesting. How much work would that part be?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate