I wrote:
I did some hacking on this and came up with the attached patch, which
could use a bit more work on the comments but passes regression tests.
However, this just solves the issue of being smart about top-level
UNION ALL cases. It might be worth looking into using MergeAppend
for the
On Mon, Nov 8, 2010 at 1:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I did some hacking on this and came up with the attached patch, which
could use a bit more work on the comments but passes regression tests.
However, this just solves the issue of being smart about top-level
UNION ALL
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 8, 2010 at 1:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But this all looks like a pretty substantial amount of work, and
given the low level of user demand for improving the performance of
set operations, it seems to belong fairly far down
On Mon, Nov 8, 2010 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 8, 2010 at 1:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But this all looks like a pretty substantial amount of work, and
given the low level of user demand for improving the
Tom Lane t...@sss.pgh.pa.us writes:
But this all looks like a pretty substantial amount of work, and
given the low level of user demand for improving the performance of
set operations, it seems to belong fairly far down the to-do list.
Whatever you say, that's your own todo list after all. I
BTW, one other point for the archives, before I forget it: it'd probably
also be wise to change the parser's output representation of set
operations. I think it should create a separate RTE entry corresponding
to each SetOperation node, similar to what we do for explicit JOIN
nodes. Then there
I wrote:
The oversight here is that we don't use appendrel planning for
a top-level UNION ALL construct. That didn't use to matter,
because you always got the same stupid Append plan either way.
Now it seems like we ought to have some more intelligence for the
top-level SetOp case. I smell
On Thu, Oct 21, 2010 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The plan for UNION initially involves a couple of SubqueryScan nodes,
which impose an extra cost of cpu_tuple_cost per tuple. Those later
get optimized away, but we don't try to readjust the cost estimates
for that.
Thanks.
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Thu, Oct 21, 2010 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The plan for UNION initially involves a couple of SubqueryScan nodes,
which impose an extra cost of cpu_tuple_cost per tuple. Â Those later
get optimized away, but we don't
On Thu, Oct 21, 2010 at 6:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thanks. It also explains my another question why Merge Append cannot
be used for UNION ALL plans.
Hmm, seems like the example you show ought to work. I wonder if there
was an oversight in that patch...
Huh, that definitely
Greg Stark gsst...@mit.edu writes:
On Thu, Oct 21, 2010 at 6:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thanks. It also explains my another question why Merge Append cannot
be used for UNION ALL plans.
Hmm, seems like the example you show ought to work. I wonder if there
was an oversight in
On Oct 21, 2010, at 2:17 PM, Tom Lane wrote:
The oversight here is that we don't use appendrel planning for
a top-level UNION ALL construct. That didn't use to matter,
because you always got the same stupid Append plan either way.
Now it seems like we ought to have some more intelligence for
Itagaki Takahiro itagaki.takah...@gmail.com writes:
I found an explicit UNION ALL has higher cost than an automatic expansion
by inheritance (49 vs. 83 in the example below). Where does the difference
come from?
The plan for UNION initially involves a couple of SubqueryScan nodes,
which impose
13 matches
Mail list logo
