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 to aggregation (and if parallel processing is not
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) then
> neither combin
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 across rows will have TransValu
>
>> 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
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 relation
> >> (join or base) returns
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 limitation to estimate th
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), so the benefit on practical
> >> examples
> >> is likely muc
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, which isn't true for
all agg
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 efficient to
>> have those aggregates combined across pa
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 because we couldn't write it
>>> for array_agg() or string_agg(). I guess, it won't be e
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 efficient to
>> have those aggregates combined across paralle
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 there are many cases where it would
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
>> "multiplying" across the rows or "concatenating" across the
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, Antonin Houska wrote:
I've been t
[ 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 been thinking about this aggtransmultifn and I'm
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 string_agg(). They need a different
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 TABLE t2 (c INT, d INT);
And let'
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 assume each table has 100.000 row
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 look like
a.i |
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
>
> 1 |
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
>> > relation level. If the relations contain relatively small number of groups,
>
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 reduced
> this way.
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 number of
>> groups,
>> the number of i
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
> reduced
> this way
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 reduced
> this way.
25 matches
Mail list logo
