From: | Richard Guo <riguo(at)pivotal(dot)io> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Jesse Zhang <sbjesse(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Pengzhou Tang <ptang(at)pivotal(dot)io>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel grouping sets |
Date: | 2020-02-03 09:27:22 |
Message-ID: | CAN_9JTw2qhj+oK-jfGoTEk5rE6qpnZ7wNYtFaHz7JXTcxGKMNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Amit,
Thanks for reviewing these two patches.
On Sat, Jan 25, 2020 at 6:31 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> This is what I also understood after reading this thread. So, my
> question is why not just review v3 and commit something on those lines
> even though it would take a bit more time. It is possible that if we
> decide to go with v5, we can make it happen earlier, but later when we
> try to get v3, the code committed as part of v5 might not be of any
> use or if it is useful, then in which cases?
>
Yes, approach #2 (v3) would be generally better than approach #1 (v5) in
performance. I started with approach #1 because it is much easier.
If we decide to go with approach #2, I think we can now concentrate on
v3 patch.
For v3 patch, we have some other idea, which is to perform a normal
grouping sets aggregation in the final phase, with 'GroupingSetId'
included in the group keys (as described in the previous email). With
this idea, we can avoid a lot of hacky codes in current v3 patch.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-02-03 09:37:25 | Re: base backup client as auxiliary backend process |
Previous Message | Kasahara Tatsuhito | 2020-02-03 09:20:49 | Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read) |