hlinnaka; robertmhaas; pgsql
Subject: Re: Re: parallel distinct union and aggregate support patch
On Tue, 30 Mar 2021 at 22:33, bu...@sohu.com wrote:
> I have written a plan with similar functions, It is known that the following
> two situations do not work well.
I read through this thread an
On Tue, 30 Mar 2021 at 22:33, bu...@sohu.com wrote:
> I have written a plan with similar functions, It is known that the following
> two situations do not work well.
I read through this thread and also wondered about a Parallel
Partition type operator. It also seems to me that if it could be do
> This patch has not gotten any review in the last two CFs and is unlikely
> to be committed for PG14 so I have moved it to the 2021-07 CF. A rebase
> is also required so marked Waiting for Author.
>
> I can see this is a work in progress, but you may want to consider the
> several suggestions th
> 1.
> +#define BATCH_SORT_MAX_BATCHES 512
>
> Did you decide this number based on some experiment or is there some
> analysis behind selecting this number?
When there are too few batches, if a certain process works too slowly, it will
cause unbalanced load.
When there are too many batches, FD
On Sun, Nov 8, 2020 at 11:54 AM Dilip Kumar wrote:
>
> On Tue, Nov 3, 2020 at 6:06 PM Dilip Kumar wrote:
> >
> > On Thu, Oct 29, 2020 at 12:53 PM bu...@sohu.com wrote:
> > >
> > > > 1) It's better to always include the whole patch series - including the
> > > > parts that have not changed. Other
On Tue, Nov 3, 2020 at 6:06 PM Dilip Kumar wrote:
>
> On Thu, Oct 29, 2020 at 12:53 PM bu...@sohu.com wrote:
> >
> > > 1) It's better to always include the whole patch series - including the
> > > parts that have not changed. Otherwise people have to scavenge the
> > > thread and search for all t
On Thu, Oct 29, 2020 at 12:53 PM bu...@sohu.com wrote:
>
> > 1) It's better to always include the whole patch series - including the
> > parts that have not changed. Otherwise people have to scavenge the
> > thread and search for all the pieces, which may be a source of issues.
> > Also, it confus
> 1) It's better to always include the whole patch series - including the
> parts that have not changed. Otherwise people have to scavenge the
> thread and search for all the pieces, which may be a source of issues.
> Also, it confuses the patch tester [1] which tries to apply patches from
> a sing
> On Tue, Oct 27, 2020 at 3:27 PM Dilip Kumar wrote:
> >
> > On Fri, Oct 23, 2020 at 11:58 AM bu...@sohu.com wrote:
> > >
> > > > Interesting idea. So IIUC, whenever a worker is scanning the tuple it
> > > > will directly put it into the respective batch(shared tuple store),
> > > > based on the
On Tue, Oct 27, 2020 at 3:27 PM Dilip Kumar wrote:
>
> On Fri, Oct 23, 2020 at 11:58 AM bu...@sohu.com wrote:
> >
> > > Interesting idea. So IIUC, whenever a worker is scanning the tuple it
> > > will directly put it into the respective batch(shared tuple store),
> > > based on the hash on group
On Fri, Oct 23, 2020 at 11:58 AM bu...@sohu.com wrote:
>
> > Interesting idea. So IIUC, whenever a worker is scanning the tuple it
> > will directly put it into the respective batch(shared tuple store),
> > based on the hash on grouping column and once all the workers are
> > doing preparing the
> Interesting idea. So IIUC, whenever a worker is scanning the tuple it
> will directly put it into the respective batch(shared tuple store),
> based on the hash on grouping column and once all the workers are
> doing preparing the batch then each worker will pick those baches one
> by one, perfor
> If I understood correctly, the tuples emitted by Parallel Batch Sort
> in each process are ordered by (hash(key, ...) % npartitions, key,
> ...), but the path is claiming to be ordered by (key, ...), no?
> That's enough for Unique and Aggregate to give the correct answer,
> because they really on
13 matches
Mail list logo
