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
27 matches
Mail list logo
