Re: [HACKERS] Partition-wise aggregation/grouping - Mailing list pgsql-hackers

From Jeevan Chalke
Subject Re: [HACKERS] Partition-wise aggregation/grouping
Date
Msg-id CAM2+6=W7nm2qt1DSATDMjTvY3MjM6x9-AgHuLt01roxA3FjWHA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Partition-wise aggregation/grouping  (Antonin Houska <ah@cybertec.at>)
Responses Re: [HACKERS] Partition-wise aggregation/grouping  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers


On Thu, Apr 27, 2017 at 4:53 PM, Antonin Houska <ah@cybertec.at> wrote:
Robert Haas <robertmhaas@gmail.com> wrote:

> On Wed, Apr 26, 2017 at 6:28 AM, Antonin Houska <ah@cybertec.at> wrote:
> > Attached is a diff that contains both patches merged. This is just to prove my
> > assumption, details to be elaborated later. The scripts attached produce the
> > following plan in my environment:
> >
> >                    QUERY PLAN
> > ------------------------------------------------
> >  Parallel Finalize HashAggregate
> >    Group Key: b_1.j
> >    ->  Append
> >          ->  Parallel Partial HashAggregate
> >                Group Key: b_1.j
> >                ->  Hash Join
> >                      Hash Cond: (b_1.j = c_1.k)
> >                      ->  Seq Scan on b_1
> >                      ->  Hash
> >                            ->  Seq Scan on c_1
> >          ->  Parallel Partial HashAggregate
> >                Group Key: b_2.j
> >                ->  Hash Join
> >                      Hash Cond: (b_2.j = c_2.k)
> >                      ->  Seq Scan on b_2
> >                      ->  Hash
> >                            ->  Seq Scan on c_2
>
> Well, I'm confused.  I see that there's a relationship between what
> Antonin is trying to do and what Jeevan is trying to do, but I can't
> figure out whether one is a subset of the other, whether they're both
> orthogonal, or something else.  This plan looks similar to what I
> would expect Jeevan's patch to produce,

The point is that the patch Jeevan wanted to work on is actually a subset of
[1] combined with [2].

Seems like, as you are targeting every relation whether or not it is
partitioned. Where as I am targeting only partitioned relations in my
patch.
 

> except i have no idea what "Parallel" would mean in a plan that contains no
> Gather node.

parallel_aware field was set mistakenly on the AggPath. Fixed patch is
attached below, producing this plan:

                   QUERY PLAN
------------------------------------------------
 Finalize HashAggregate
   Group Key: b_1.j
   ->  Append
         ->  Partial HashAggregate
               Group Key: b_1.j
               ->  Hash Join
                     Hash Cond: (b_1.j = c_1.k)
                     ->  Seq Scan on b_1
                     ->  Hash
                           ->  Seq Scan on c_1
         ->  Partial HashAggregate
               Group Key: b_2.j
               ->  Hash Join
                     Hash Cond: (b_2.j = c_2.k)
                     ->  Seq Scan on b_2
                     ->  Hash
                           ->  Seq Scan on c_2

With my patch, I am getting following plan where we push entire
aggregation below append.

                QUERY PLAN               
------------------------------------------
 Append
   ->  HashAggregate
         Group Key: b_1.j
         ->  Hash Join
               Hash Cond: (b_1.j = c_1.k)
               ->  Seq Scan on b_1
               ->  Hash
                     ->  Seq Scan on c_1
   ->  HashAggregate
         Group Key: b_2.j
         ->  Hash Join
               Hash Cond: (b_2.j = c_2.k)
               ->  Seq Scan on b_2
               ->  Hash
                     ->  Seq Scan on c_2
(15 rows)


Antonin, I have tried applying your patch on master but it doesn't get
apply. Can you please provide the HEAD and any other changes required
to be applied first?

How the plan look like when GROUP BY key does not match with the
partitioning key i.e. GROUP BY b.v ?
 

[1] https://www.postgresql.org/message-id/9666.1491295317%40localhost

[2] https://commitfest.postgresql.org/14/994/

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers




--
Jeevan Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: +91 20 66449694

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Declarative partitioning - another take