Re: Parallel grouping sets - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel grouping sets
Date
Msg-id CAA4eK1LL8QQgNHw3-CtxAG8ZbyHJWM2+xSi5tTrB7mjNy_Ughw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel grouping sets  (Jesse Zhang <sbjesse@gmail.com>)
Responses Re: Parallel grouping sets  (Richard Guo <riguo@pivotal.io>)
List pgsql-hackers
On Sat, Jan 25, 2020 at 4:22 AM Jesse Zhang <sbjesse@gmail.com> wrote:
>
> On Thu, Jan 23, 2020 at 2:47 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Sun, Jan 19, 2020 at 2:23 PM Richard Guo <riguo@pivotal.io> wrote:
> > >
> > > I realized that there are two patches in this thread that are
> > > implemented according to different methods, which causes confusion.
> > >
> >
> > Both the idea seems to be different.  Is the second approach [1]
> > inferior for any case as compared to the first approach?  Can we keep
> > both approaches for parallel grouping sets, if so how?  If not, then
> > won't the code by the first approach be useless once we commit second
> > approach?
> >
> >
> > [1] - https://www.postgresql.org/message-id/CAN_9JTwtTTnxhbr5AHuqVcriz3HxvPpx1JWE--DCSdJYuHrLtA%40mail.gmail.com
> >
>
> I glanced over both patches. Just the opposite, I have a hunch that v3
> is always better than v5.
>

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?


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Allow to_date() and to_timestamp() to accept localized names
Next
From: Dent John
Date:
Subject: Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR