Prev: - GSoC - snapshot materialized view (work-in-progress) patch
Next: [HACKERS] dblink regression failure in HEAD
From: Hitoshi Harada on 3 Aug 2010 12:30
2010/7/21 David Fetter <david(a)fetter.org>:
> On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
>> 2010/7/17 Marko Tiikkaja <marko.tiikkaja(a)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 ;)

Yeah, that would be handiest, but I think I must wait for his first
compilable patch to modify to try the idea. Current version looks
quite messy and can't build.

>> >> 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?

FWIW, this is getting interesting to me these days, and I think this
can be separated from wCTE

As hackers say, the first to try should be Marko's first design that
use the list of tuplestore and DTScanNode. So if he has solid image to
reach there, we can wait for him to complete his first compilable
version. Then let's take it back and forth. Is it possible?

And I concern we might not have concrete consensus about list of
features in document form. Does it accept Recursive query? What if x
refers to y that refers to x cyclicly? An external design sometimes
fix the internal design, and it helps people to review the
implementation. If I missed something please point me to the link.


Regards,


--
Hitoshi Harada

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Marko Tiikkaja on 3 Aug 2010 13:54
On 8/3/2010 7:30 PM, Hitoshi Harada wrote:
> As hackers say, the first to try should be Marko's first design that
> use the list of tuplestore and DTScanNode. So if he has solid image to
> reach there, we can wait for him to complete his first compilable
> version. Then let's take it back and forth. Is it possible?

I am currently working on a version that treats all WITH queries like
wCTEs. My progress can be seen in my git repo [1], branch "wcte". In
its current form, the patch compiles and passes all applicable
regression tests but it's still very messy. I'm going to send a cleaner
WIP patch to the list the minute I have one, but anyone's free to look
at the git repo (and even work on it if they want!).

> And I concern we might not have concrete consensus about list of
> features in document form. Does it accept Recursive query? What if x
> refers to y that refers to x cyclicly? An external design sometimes
> fix the internal design, and it helps people to review the
> implementation. If I missed something please point me to the link.

A recursive query should be fine as long as 1) it's SELECT-only and 2)
it doesn't loop forever. A wCTE can of course refer to the result of
the recursive SELECT query with INSERT .. SELECT, UPDATE .. FROM or
DELETE .. USING. Cyclic dependencies are out of the scope of this
patch; I'm not planning on adding any new features to regular CTEs.


[1] http://git.postgresql.org/gitweb?p=users/johto/postgres.git;a=summary


Regards,
Marko Tiikkaja

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3
Prev: - GSoC - snapshot materialized view (work-in-progress) patch
Next: [HACKERS] dblink regression failure in HEAD