> > for now fuction cost_subqueryscan always using *total* rows even parallel
> > path. like this:
> >
> > Gather (rows=3)
> > Workers Planned: 2
> > -> Subquery Scan (rows=3) -- *total* rows, should be equal subpath
> > -> Parallel Seq Scan (rows=1)
>
> OK, that's
row estimate */
if (path->path.parallel_workers > 0)
path->path.rows = path->subpath->rows;
else if (param_info)
path->path.rows = param_info->ppi_rows;
else
path->path.rows = baserel->rows;
bu...@sohu.com
> Generally it should be. But there's no subquery scan visible here.
I wrote a patch for distinct/union and aggregate support last year(I want
restart it again).
https://www.postgresql.org/message-id/2021091517250848215321%40sohu.com
If not apply this patch, some parallel paths will naver be
ort
Sort Key: t.a, t.b, t.c
-> Gather
Workers Planned: 2
-> Parallel Append
-> Parallel Seq Scan on t
-> Parallel Seq Scan on t t_1
Obviously the latter is
loop". but "grouping sets" can not work in parallel mode using
"Parallel Redistribute".
Wait days please, path coming soon.
From: David Rowley
Date: 2021-07-06 10:48
To: bu...@sohu.com
CC: David Steele; pgsql-hackers; tgl; Dilip Kumar; Thomas Munro; Tomas Vondra;
hlin
At some point might be the case: parallel worker 1 executing Agg and
"Parallel Redistribute" plan's memory buffer is full,
worker 2 executing "Parallel Redistribute" and it waiting worker 1 eat
"Parallel Redistribute" plan's memory buffer,
it's stuck.
bu...@sohu.com
VA_ARGS_NARGS(__VA_ARGS__), _int, __VA_ARGS__)
#define list_make_oid(...) MACRO_COMBIN_3(list_make, MACRO_ARGS
VA_ARGS_NARGS(__VA_ARGS__), _oid, __VA_ARGS__)
bu...@sohu.com
From: Tom Lane
Date: 2019-02-24 10:24
To: pgsql-hackers
Subject: POC: converting Lists into arrays
For quite some years now
> 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
> 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
batch store module.
By the way, use atomic operations instead LWLock for shared tuple store get
next read page.
patch 4:
using batch hash agg support parallels
发件人： bu...@sohu.com
发送时间： 2020-10-19 22:42
收件人： pgsql-hackers
主题： parallel distinct union and aggregate support patch
Hi hackers,
I
> 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 res
> 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,
plan could break", mean some on path
using this path? no, BathSortPath on for some special path(Unique, GroupAgg
...).
bu...@sohu.com
From: Thomas Munro
Date: 2020-10-21 12:27
To: bu...@sohu.com
CC: pgsql-hackers
Subject: Re: parallel distinct union and aggregate support patch
On Tue
分布式数据库产品AntDB，开源地址 https://github.com/ADBSQL/AntDB
bu...@sohu.com
0001-Parallel-distinct-and-union-support.patch
Description: Binary data
0002-Parallel-aggregate-support-using-batch-sort.patch
Description: Binary data
14 matches
Mail list logo
