On Thu, Oct 14, 2010 at 8:34 AM, Tom Lane wrote:
> I did run into a problem with my plan to call the new node type "Merge":
> the planner is already using "MergePath" as the name for the Path struct
> that is precursor to a MergeJoin. For the moment I'm calling the new
> node type MergeAppend, bu
Robert Haas writes:
> So I tried out the logic described in this email and, with a few
> modifications, it seemed to work. Updated patch attached, any review
> appreciated.
Applied with revisions.
>> 3. TGL: "Speaking of sorting, it's not entirely clear to me how the
>> patch ensures that all t
Robert Haas writes:
> On Thu, Oct 14, 2010 at 11:34 AM, Tom Lane wrote:
>> Anybody have a strong feeling about what to call these things?
>> At the moment I'm leaning to sticking with MergeAppend, but if we
>> decide to rename it it'd probably be better to do so before committing.
> I don't like
On Thu, Oct 14, 2010 at 11:34 AM, Tom Lane wrote:
> I wrote:
>> I rather wonder if we don't want two separate
>> execution-time node types anyway, since what Append does seems
>> significantly different from Merge (and MergeAppend would be just a
>> misnomer).
>
> I've been working on this patch,
I wrote:
> I rather wonder if we don't want two separate
> execution-time node types anyway, since what Append does seems
> significantly different from Merge (and MergeAppend would be just a
> misnomer).
I've been working on this patch, and have gotten the executor side split
out as a new node ty
Robert Haas writes:
> Another awkwardness of this patch is that it makes
> create_append_path() and consequently set_dummy_rel_pathlist() take an
> additional "root" argument. While there's nothing terribly
> unreasonable about this on its face, it's only necessary so that
> create_append_path()
On Wed, Sep 29, 2010 at 11:01 AM, Robert Haas wrote:
> Makes sense to me. It seems that there are actually two halves to
> this problem: getting the child EMs to be generated in the first
> place, and then getting them to be examined at the appropriate time.
So I tried out the logic described in
2010/9/23 Robert Haas :
> All of this leaves me wondering why Greg ended up ifdefing out this
> code in the first place. There's probably something I'm missing
> here... but for now I can't think of a better idea than just removing
> the #ifdefs and hoping that whatever problem they were causing
On Tue, Sep 28, 2010 at 11:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> ...what makes the pathkeys potentially useful is that they match the
>> root pathkeys for the query. However, without Greg's hacks, the
>> transposed child equivalence classes don't show up in the equivalence
>> member li
Robert Haas writes:
> ...what makes the pathkeys potentially useful is that they match the
> root pathkeys for the query. However, without Greg's hacks, the
> transposed child equivalence classes don't show up in the equivalence
> member lists, so get_eclass_for_sort_expr() generates new equivale
2010/9/28 Robert Haas :
> 2010/9/23 Robert Haas :
>> All of this leaves me wondering why Greg ended up ifdefing out this
>> code in the first place. There's probably something I'm missing
>> here... but for now I can't think of a better idea than just removing
>> the #ifdefs and hoping that whate
2010/9/23 Robert Haas :
> All of this leaves me wondering why Greg ended up ifdefing out this
> code in the first place. There's probably something I'm missing
> here... but for now I can't think of a better idea than just removing
> the #ifdefs and hoping that whatever problem they were causing
On Fri, Sep 24, 2010 at 5:05 PM, Tom Lane wrote:
> It's not that hard if you just tweak equivclass.c to make the order of
> equivalence-class lists different, viz
[...]
> Since the order of equivalence-class member lists isn't supposed to be
> semantically significant, I claim that the code in cre
Robert Haas writes:
> FIXME #1 and FIXME #2 were much harder to trigger. In fact, barring
> significant further lobotimization of the code, I couldn't.
It's not that hard if you just tweak equivclass.c to make the order of
equivalence-class lists different, viz
diff --git a/src/backend/optimize
2010/9/20 Robert Haas :
> 4. TGL: "In any case, I'm amazed that it's not failing regression
> tests all over the place with those critical tests in
> make_sort_from_pathkeys lobotomized by random #ifdef FIXMEs. Perhaps
> we need some more regression tests...". Obviously, we need to remove
> that
2010/9/23 Hans-Jürgen Schönig :
> sorry for not getting back to you sooner. i am currently on the road for some
> days.
> we got the top 3 things fixed already. however, some code seems to be relying
> on a sorted list somewhere(???).
> we are in the process of sorting out most of the stuff.
> i
On Sep 23, 2010, at 3:29 PM, Robert Haas wrote:
> On Tue, Sep 21, 2010 at 12:29 AM, David Fetter wrote:
>> On Mon, Sep 20, 2010 at 10:57:00PM -0400, Robert Haas wrote:
>>> 2010/9/3 Hans-Jürgen Schönig :
On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
> I agree. Explicit partitioning may o
On Tue, Sep 21, 2010 at 12:29 AM, David Fetter wrote:
> On Mon, Sep 20, 2010 at 10:57:00PM -0400, Robert Haas wrote:
>> 2010/9/3 Hans-Jürgen Schönig :
>> > On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
>> >> I agree. Explicit partitioning may open up some additional
>> >> optimization possibiliti
On Mon, Sep 20, 2010 at 10:57:00PM -0400, Robert Haas wrote:
> 2010/9/3 Hans-Jürgen Schönig :
> > On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
> >> I agree. Explicit partitioning may open up some additional
> >> optimization possibilities in certain cases, but Merge Append is
> >> more general an
2010/9/3 Hans-Jürgen Schönig :
> On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
>> I agree. Explicit partitioning may open up some additional optimization
>> possibilities in certain cases, but Merge Append is more general and
>> extremely valuable in its own right.
>
> we have revised greg's won
On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
> On Sep 1, 2010, at 10:21 AM, Greg Stark wrote:
>> For what it's worth I disagree with Tom. I think this is a situation
>> where we need *both* types of solution. Ideally we will be able to use
>> a plain Append node for cases where we know the rel
On Sep 1, 2010, at 10:21 AM, Greg Stark wrote:
> For what it's worth I disagree with Tom. I think this is a situation
> where we need *both* types of solution. Ideally we will be able to use
> a plain Append node for cases where we know the relative ordering of
> the data in different partitions,
hello tom,
yeah, we have followed quite a lot of discussion as well ...
and yes, no patches.
as far as this problem is concerned: we are working on a patch and did some
prototyping inside the planner already (attached).
the code we have is pretty limited atm (such as checking for a sort clause
=?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?=
writes:
> On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
>> This is really premature, and anything you do along those lines now will
>> probably never get committed.
> well, why non-overlapping? the idea is to make append smart enough to
> take
On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
> Boszormenyi Zoltan writes:
>> we are experimenting with modifying table partitioning
>> so the ORDER BY clause can be pushed down to
>> child nodes on the grounds that:
>
> This is really premature, and anything you do along those lines now will
> pr
2010/9/1 Boszormenyi Zoltan :
> we are experimenting with modifying table partitioning
> so the ORDER BY clause can be pushed down to
> child nodes on the grounds that:
> 1. smaller datasets are faster to sort, e.g. two datasets that almost
> spill out to disk are faster to sort in memory and la
Boszormenyi Zoltan writes:
> we are experimenting with modifying table partitioning
> so the ORDER BY clause can be pushed down to
> child nodes on the grounds that:
This is really premature, and anything you do along those lines now will
probably never get committed. The problem is that the tra
Hi,
we are experimenting with modifying table partitioning
so the ORDER BY clause can be pushed down to
child nodes on the grounds that:
1. smaller datasets are faster to sort, e.g. two datasets that almost
spill out to disk are faster to sort in memory and later merge them
than the union
28 matches
Mail list logo
