Prev: - GSoC - snapshot materialized view (work-in-progress) patch
Next: [HACKERS] dblink regression failure in HEAD
From: Marko Tiikkaja on 12 Jul 2010 14:21
On 7/12/10 9:07 PM +0300, I wrote:
> Consider:
>
> WITH t AS (SELECT 1),
> t2 AS (SELECT * FROM t2)
> VALUES (true);

That should of course have been SELECT * FROM t, not t2.


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

From: Tom Lane on 12 Jul 2010 14:34
Marko Tiikkaja <marko.tiikkaja(a)cs.helsinki.fi> writes:
> ... So what I'm now thinking of is making the planner plan that as a single
> Query, and make the planner expand it into multiple PlannedStmts if
> necessary. This would break the existing planner hooks, but I don't
> think that's a huge problem. Does anyone see any obvious flaws in this?

How will that interact with the existing rewriter? It sounds a lot
like a recipe for duplicating functionality ...

regards, tom lane

--
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 12 Jul 2010 14:41
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
> Marko Tiikkaja<marko.tiikkaja(a)cs.helsinki.fi> writes:
>> ... So what I'm now thinking of is making the planner plan that as a single
>> Query, and make the planner expand it into multiple PlannedStmts if
>> necessary. This would break the existing planner hooks, but I don't
>> think that's a huge problem. Does anyone see any obvious flaws in this?
>
> How will that interact with the existing rewriter? It sounds a lot
> like a recipe for duplicating functionality ...

I was thinking that the rewriter would look at the top-level CTEs and
rewrite all non-SELECT queries into a list of Queries and store that
list into the CommonTableExprs. The planner would then use this
information and also expand the rewrite products.


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

From: Hitoshi Harada on 16 Jul 2010 11:15
2010/7/13 Marko Tiikkaja <marko.tiikkaja(a)cs.helsinki.fi>:
> Hi,
>
>
> I've been working on writeable CTEs during the last couple of months, but
> right now it looks like I'm going to miss the first commit fest for 9.1. �I
> was trying to make it work by expanding all wCTEs to their own Queries
> during the rewrite stage (a very crude patch trying to do that for regular
> CTEs attached), but I don't think that it's a good way of approaching the
> problem. �Consider:

Sorry it's not relevant to the topic you post but it seems you're
going to add new executor node called DtScanNode and let it hold
tuplestore passed by the Query indicated by index number. However, I
suppose there are other ways:

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.
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'm not familiar with the long discussion on this feature so not sure
they are possible, but ISTM they are enough to be discussed (or
discussed already?).


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 16 Jul 2010 11:52
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
> Sorry it's not relevant to the topic you post but ..

Relevant enough :-)

> .. it seems you're
> going to add new executor node called DtScanNode and let it hold
> tuplestore passed by the Query indicated by index number. However, I
> suppose there are other ways:
>
> 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.

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

> I'm not familiar with the long discussion on this feature so not sure
> they are possible, but ISTM they are enough to be discussed (or
> discussed already?).

We haven't discussed this part of the design yet.. Now is a good time
to do it.


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

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