2010/7/13 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@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
2010/7/21 David Fetter da...@fetter.org:
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@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
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
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@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
On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@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
On Tue, Jul 20, 2010 at 5:13 PM, Merlin Moncure mmonc...@gmail.com wrote:
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
2010/7/13 Marko Tiikkaja marko.tiikk...@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
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
2010/7/17 Marko Tiikkaja marko.tiikk...@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
On 7/16/10 7:15 PM +0300, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkajamarko.tiikk...@cs.helsinki.fi:
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
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
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@postgresql.org)
To make changes to your
Marko Tiikkaja marko.tiikk...@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
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@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,
14 matches
Mail list logo
