Re: Parallel grouping sets
От | Richard Guo |
---|---|
Тема | Re: Parallel grouping sets |
Дата | |
Msg-id | CAN_9JTw2qhj+oK-jfGoTEk5rE6qpnZ7wNYtFaHz7JXTcxGKMNA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel grouping sets (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
Hi Amit,
Thanks for reviewing these two patches.
On Sat, Jan 25, 2020 at 6:31 PM Amit Kapila <amit.kapila16@gmail.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.
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
В списке pgsql-hackers по дате отправления: