Subject: Re: [HACKERS] upper planner path-ification
>
> On Tue, Jun 23, 2015 at 4:41 AM, Kouhei Kaigai wrote:
> > So, unless we don't find out a solution around planner, 2-phase aggregation
> > is
> > like a curry without rice
>
> Simon and I spoke with Tom ab
On Tue, Jun 23, 2015 at 4:41 AM, Kouhei Kaigai wrote:
> So, unless we don't find out a solution around planner, 2-phase aggregation is
> like a curry without rice
Simon and I spoke with Tom about this upper planner path-ification
problem at PGCon, and he indicated that he intended to work on
> -Original Message-
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Sent: Tuesday, June 23, 2015 2:06 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Robert Haas; pgsql-hackers@postgresql.org; Tom Lane
> Subject: Re: [HACKERS] upper planner path-ification
>
>
&g
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Monday, May 18, 2015 1:12 AM
> To: Robert Haas
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] upper planner path-
On 23 June 2015 at 13:55, Kouhei Kaigai wrote:
> Once we support to add aggregation path during path consideration,
> we need to pay attention morphing of the final target-list according
> to the intermediate path combination, tentatively chosen.
> For example, if partial-aggregation makes sense
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Thursday, May 14, 2015 10:39 AM
> To: pgsql-hackers@postgresql.org; Tom Lane
> Subject: [HACKERS] upper planner path-ification
At Tue, 19 May 2015 09:04:00 -0400, Robert Haas wrote
in
> On Tue, May 19, 2015 at 7:19 AM, Andrew Gierth
> wrote:
> >> "Tom" == Tom Lane writes:
> > Tom> Hm. That's a hangover from when query_planner also gave back a
> > Tom> Plan (singular) rather than a set of Paths. I don't see any
On Tue, May 19, 2015 at 7:19 AM, Andrew Gierth
wrote:
>> "Tom" == Tom Lane writes:
> Tom> Hm. That's a hangover from when query_planner also gave back a
> Tom> Plan (singular) rather than a set of Paths. I don't see any
> Tom> fundamental reason why we couldn't generalize it to be a list
> "Tom" == Tom Lane writes:
Tom> Hm. That's a hangover from when query_planner also gave back a
Tom> Plan (singular) rather than a set of Paths. I don't see any
Tom> fundamental reason why we couldn't generalize it to be a list of
Tom> potentially useful output orderings rather than jus
On Mon, May 18, 2015 at 2:50 PM, Tom Lane wrote:
>> I don't know, but it seems like this might be pulling in the opposite
>> direction from your previously-stated desire to get subquery_planner
>> to output Paths rather than Plans as soon as possible.
>
> Sorry, I didn't mean to suggest that that
Simon Riggs writes:
> On 18 May 2015 at 14:50, Tom Lane wrote:
>> So for the moment, let's assume that we still rigidly follow the sequence
>> of upper-level steps currently embodied in grouping_planner. (I'm not
>> sure if it even makes sense to consider other orderings of those
>> processing s
On 18 May 2015 at 14:50, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, May 17, 2015 at 12:11 PM, Tom Lane wrote:
> >> Rather than adding tlists per se to Paths, I've been vaguely toying with
> >> a notion of identifying all the "interesting" subexpressions in a query
> >> (expensive functio
Robert Haas writes:
> On Sun, May 17, 2015 at 12:11 PM, Tom Lane wrote:
>> Rather than adding tlists per se to Paths, I've been vaguely toying with
>> a notion of identifying all the "interesting" subexpressions in a query
>> (expensive functions, aggregates, etc), giving them indexes 1..n, and t
On Sun, May 17, 2015 at 12:11 PM, Tom Lane wrote:
> Rather than adding tlists per se to Paths, I've been vaguely toying with
> a notion of identifying all the "interesting" subexpressions in a query
> (expensive functions, aggregates, etc), giving them indexes 1..n, and then
> marking Paths with b
Andrew Gierth writes:
> Incidentally, the most obvious obstacle to better planning of grouping
> sets in the sorted cases is not so much how to pick paths in
> grouping_planner itself, but rather the fact that query_planner wants to
> be given only one sort order. Is there any prospect for improve
> "Tom" == Tom Lane writes:
>> Hrm, ok. So for the near future, we should leave it more or less
>> as-is? We don't have a timescale yet, but it's our intention to
>> submit a hashagg support patch for grouping sets as soon as time
>> permits.
Tom> Well, mumble. I keep saying that I wa
Robert Haas writes:
> So, getting back to this part, what's the value of returning a list of
> Paths rather than a list of Plans?
(1) less work, since we don't have to fill in details not needed for
costing purposes;
(2) paths carry info that the planner wants but the executor doesn't,
no
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> So I'm all for refactoring, but I think it will happen as a natural
> Tom> byproduct of path-ification, and otherwise would be rather forced.
> Hrm, ok. So for the near future, we should leave it more or less as-is?
> We don't have a tim
> "Tom" == Tom Lane writes:
>> If there's interest, we could do that specific task as part of
>> adding hashagg support for grouping sets (which would otherwise make
>> it even longer), or as preparatory work for that.
Tom> I think that refactoring without changing anything about the way
Andrew Gierth writes:
> "Robert" == Robert Haas writes:
> Robert> I think grouping_planner() is badly in need of some refactoring
> Robert> just to make it shorter. It's over 1000 lines of code, which
> Robert> IMHO is a fairly ridiculous length for a single function.
> If there's interest,
> "Robert" == Robert Haas writes:
Robert> I think grouping_planner() is badly in need of some refactoring
Robert> just to make it shorter. It's over 1000 lines of code, which
Robert> IMHO is a fairly ridiculous length for a single function.
If there's interest, we could do that specific
On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote:
> For the reasons I mentioned, I'd like to get to a point where
> subquery_planner's output is Paths not Plans as soon as possible. But the
> idea of coarse representation of steps that we aren't trying to be smart
> about might be useful to save
On Thu, May 14, 2015 at 8:24 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote:
> >> For the reasons I mentioned, I'd like to get to a point where
> >> subquery_planner's output is Paths not Plans as soon as possible. But
> the
> >> idea of coarse r
On Thu, May 14, 2015 at 7:09 AM, Robert Haas wrote:
> Hi,
>
> I've been pulling over Tom's occasional remarks about redoing
> grouping_planner - and maybe further layers of the planner - to work
> with Paths instead of Plans. I've had difficulty locating all of the
> relevant threads. Here's ev
On Thu, May 14, 2015 at 12:19:44PM -0400, Robert Haas wrote:
> Well, I'm just shooting from the hip here, but it seems to me that the
> basic pipeline as it exists today is Join -> Aggregate -> SetOp ->
> Limit -> LockRows. I don't think Limit or LockRows can be moved any
> earlier. SetOps have a
On Thu, May 14, 2015 at 10:54 AM, Tom Lane wrote:
> In any case, the key question if we're to have Paths representing
> higher-level computations is "what do we hang our lists of such Paths
> off of?".
Yeah, I was wondering about that, too.
> If we have say both GROUP BY and LIMIT, it's importan
Robert Haas writes:
> On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote:
>> For the reasons I mentioned, I'd like to get to a point where
>> subquery_planner's output is Paths not Plans as soon as possible. But the
>> idea of coarse representation of steps that we aren't trying to be smart
>> abo
Hello, this topic lured me on..
At Wed, 13 May 2015 23:43:57 -0400, Robert Haas wrote
in
> On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote:
> > Both of those are problems all right, but there is more context here.
>
> Thanks for providing the context.
>
> >> I'm inclined to think that it wo
On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote:
> Both of those are problems all right, but there is more context here.
Thanks for providing the context.
>> I'm inclined to think that it would be useful to solve the first
>> problem even if we didn't solve the second one right away (but that
>
Robert Haas writes:
> I've been pulling over Tom's occasional remarks about redoing
> grouping_planner - and maybe further layers of the planner - to work
> with Paths instead of Plans. ...
> I think there are two separate problems here. First, there's the
> problem that grouping_planner() is com
Hi,
I've been pulling over Tom's occasional remarks about redoing
grouping_planner - and maybe further layers of the planner - to work
with Paths instead of Plans. I've had difficulty locating all of the
relevant threads. Here's everything I've found so far, which I'm
pretty sure is not everythi
31 matches
Mail list logo
