Re: [HACKERS] PoC: Grouped base relation

David Rowley wrote: > On 20 January 2017 at 00:22, Antonin Houska wrote: > > Sorry, it was my thinko - I somehow confused David's CROSS JOIN example with > > this one. If one side of the join clause is unique and the other becomes > > unique due

Re: [HACKERS] PoC: Grouped base relation

On 20 January 2017 at 00:22, Antonin Houska wrote: > Sorry, it was my thinko - I somehow confused David's CROSS JOIN example with > this one. If one side of the join clause is unique and the other becomes > unique due to aggregation (and if parallel processing is not engaged)

Re: [HACKERS] PoC: Grouped base relation

On Thu, Jan 19, 2017 at 2:19 AM, Tomas Vondra wrote: >> Not all aggregates have TransValue * integer = newTransValue >> behaviour. Example is array_agg() or string_agg() has "TransValue >> concatenated integer time" behaviour. Or an aggregate "multiplying" >> values

Re: [HACKERS] PoC: Grouped base relation

> >> Yes, it's hard, but I think without having a separate RelOptInfo the >> design won't be complete. Is there a subset of problem that can be >> solved by using a separate RelOptInfo e.g. pushing aggregates down >> child relations or anything else. > > I'm still not convinced that all the fields

Re: [HACKERS] PoC: Grouped base relation

Ashutosh Bapat wrote: > >> 1. Pushing down aggregates/groups down join tree, so that the number of > >> rows > >> to be joined decreases. This might be a good optimization to have. However > >> there are problems in the current patch. Every path built for a

Re: [HACKERS] PoC: Grouped base relation

Antonin Houska wrote: Well, the following one does not seem to be a typical example. I could generate the plan, but now I think that the aggregation push down does not in general decrease the number of groups the final aggregation has to process. Maybe I just hit planner

Re: [HACKERS] PoC: Grouped base relation

Tomas Vondra wrote: > On 01/17/2017 08:05 PM, Antonin Houska wrote: > > Tomas Vondra wrote: > > > > > >> Another thing is that in my experience most queries do joins on foreign > >> keys > >> (so the PK side is unique by definition),

Re: [HACKERS] PoC: Grouped base relation

On 01/19/2017 04:09 AM, Ashutosh Bapat wrote: On Thu, Jan 19, 2017 at 12:02 AM, Robert Haas wrote: On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat Also, the point is naming that kind of function as aggtransmultifn would mean that it's always supposed to multiply,

Re: [HACKERS] PoC: Grouped base relation

On Thu, Jan 19, 2017 at 12:02 AM, Robert Haas wrote: > On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat > wrote: >> I don't think aggcombinefn isn't there because we couldn't write it >> for array_agg() or string_agg(). I guess, it won't be

Re: [HACKERS] PoC: Grouped base relation

On Wed, Jan 18, 2017 at 5:14 PM, David Rowley wrote: > On 19 January 2017 at 07:32, Robert Haas wrote: >> On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat >> wrote: >>> I don't think aggcombinefn isn't there

Re: [HACKERS] PoC: Grouped base relation

On 19 January 2017 at 07:32, Robert Haas wrote: > On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat > wrote: >> I don't think aggcombinefn isn't there because we couldn't write it >> for array_agg() or string_agg(). I guess, it won't be

Re: [HACKERS] PoC: Grouped base relation

On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat wrote: > I don't think aggcombinefn isn't there because we couldn't write it > for array_agg() or string_agg(). I guess, it won't be efficient to > have those aggregates combined across parallel workers. I think

Re: [HACKERS] PoC: Grouped base relation

On Tue, Jan 17, 2017 at 10:07 PM, Antonin Houska wrote: > Ashutosh Bapat wrote: >> [... snip ]] >> >> This all works well, as long as the aggregate is "summing" something >> across rows. The method doesn't work when aggregation is say >>

Re: [HACKERS] PoC: Grouped base relation

On 01/17/2017 08:05 PM, Antonin Houska wrote: [ Trying to respond to both Tomas and David. I'll check tomorrow if anything else of the thread needs my comment. ] Tomas Vondra wrote: On 01/17/2017 12:42 AM, David Rowley wrote: On 10 January 2017 at 06:56,

Re: [HACKERS] PoC: Grouped base relation

[ Trying to respond to both Tomas and David. I'll check tomorrow if anything else of the thread needs my comment. ] Tomas Vondra wrote: > On 01/17/2017 12:42 AM, David Rowley wrote: > > On 10 January 2017 at 06:56, Antonin Houska wrote: > > I've

Re: [HACKERS] PoC: Grouped base relation

Ashutosh Bapat wrote: > [... snip ]] > > This all works well, as long as the aggregate is "summing" something > across rows. The method doesn't work when aggregation is say > "multiplying" across the rows or "concatenating" across the rows like > array_agg() or

Re: [HACKERS] PoC: Grouped base relation

On 01/17/2017 06:39 AM, David Rowley wrote: On 17 January 2017 at 16:30, Tomas Vondra wrote: Let's instead use an example similar to what Antonin mentioned in the initial post - two tables, with two columns each. CREATE TABLE t1 (a INT, b INT); CREATE

Re: [HACKERS] PoC: Grouped base relation

On 17 January 2017 at 16:30, Tomas Vondra wrote: > Let's instead use an example similar to what Antonin mentioned in the > initial post - two tables, with two columns each. > > CREATE TABLE t1 (a INT, b INT); > CREATE TABLE t2 (c INT, d INT); > > And let's

Re: [HACKERS] PoC: Grouped base relation

On 01/17/2017 12:42 AM, David Rowley wrote: On 10 January 2017 at 06:56, Antonin Houska wrote: Before performing the final aggregation, we need to multiply sum(a.x) by count(j.*) because w/o the aggregation at base relation level the input of the query-level aggregation would

Re: [HACKERS] PoC: Grouped base relation

On 10 January 2017 at 06:56, Antonin Houska wrote: > Before performing the final aggregation, we need to multiply sum(a.x) by > count(j.*) because w/o the aggregation at base relation level the input > of the query-level aggregation would look like > > a.i | a.x | b.j >

Re: [HACKERS] PoC: Grouped base relation

On Fri, Jan 13, 2017 at 10:12 PM, Antonin Houska wrote: > Ashutosh Bapat wrote: >> On Mon, Jan 9, 2017 at 11:26 PM, Antonin Houska wrote: >> > Attached is a draft patch that lets partial aggregation happen at base >> >

Re: [HACKERS] PoC: Grouped base relation

On Mon, Jan 9, 2017 at 11:26 PM, Antonin Houska wrote: > Attached is a draft patch that lets partial aggregation happen at base > relation level. If the relations contain relatively small number of groups, > the number of input rows of the aggregation at the query level can be

Re: [HACKERS] PoC: Grouped base relation

On Tue, Jan 10, 2017 at 6:52 PM, Pantelis Theodosiou wrote: > > > On Mon, Jan 9, 2017 at 5:56 PM, Antonin Houska wrote: > >> Attached is a draft patch that lets partial aggregation happen at base >> relation level. If the relations contain relatively small

Re: [HACKERS] PoC: Grouped base relation

On Mon, Jan 9, 2017 at 5:56 PM, Antonin Houska wrote: > Attached is a draft patch that lets partial aggregation happen at base > relation level. If the relations contain relatively small number of groups, > the number of input rows of the aggregation at the query level can be >

Re: [HACKERS] PoC: Grouped base relation

On Mon, Jan 9, 2017 at 12:56 PM, Antonin Houska wrote: > Attached is a draft patch that lets partial aggregation happen at base > relation level. If the relations contain relatively small number of groups, > the number of input rows of the aggregation at the query level can be