Re: Parallel Seq Scan - Mailing list pgsql-hackers
| From | Thom Brown |
|---|---|
| Subject | Re: Parallel Seq Scan |
| Date | |
| Msg-id | CAA-aLv4abguWP4-NKRcNraCxSxMB5EMhz1GM0E=r8nZ_qb1ONg@mail.gmail.com Whole thread Raw |
| In response to | Re: Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
| Responses |
Re: Parallel Seq Scan
(Thom Brown <thom@linux.com>)
Re: Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
| List | pgsql-hackers |
On 18 December 2014 at 16:03, Amit Kapila <amit.kapila16@gmail.com> wrote:
Should I really need to increase max_worker_processes to >= parallel_seqscan_degree? If so, shouldn't there be a hint here along with the error message pointing this out? And should the error be produced when only a *plan* is being requested?
On Thu, Dec 18, 2014 at 9:22 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Dec 8, 2014 at 10:40 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Sat, Dec 6, 2014 at 5:37 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > >
> >
> > So to summarize my understanding, below are the set of things
> > which I should work on and in the order they are listed.
> >
> > 1. Push down qualification
> > 2. Performance Data
> > 3. Improve the way to push down the information related to worker.
> > 4. Dynamic allocation of work for workers.
> >
> >
>
> I have worked on the patch to accomplish above mentioned points
> 1, 2 and partly 3 and would like to share the progress with community.Sorry forgot to attach updated patch in last mail, attaching it now.
When attempting to recreate the plan in your example, I get an error:
➤ psql://thom@[local]:5488/pgbench
# create table t1(c1 int, c2 char(500)) with (fillfactor=10);
CREATE TABLE
Time: 13.653 ms
➤ psql://thom@[local]:5488/pgbench
# insert into t1 values(generate_series(1,100),'amit');
INSERT 0 100
Time: 4.796 ms
➤ psql://thom@[local]:5488/pgbench
# explain select c1 from t1;
ERROR: could not register background process
HINT: You may need to increase max_worker_processes.
Time: 1.659 ms
➤ psql://thom@[local]:5488/pgbench
# show max_worker_processes ;
max_worker_processes
----------------------
8
(1 row)
Time: 0.199 ms
# show parallel_seqscan_degree ;
parallel_seqscan_degree
-------------------------
10
(1 row)
➤ psql://thom@[local]:5488/pgbench
# create table t1(c1 int, c2 char(500)) with (fillfactor=10);
CREATE TABLE
Time: 13.653 ms
➤ psql://thom@[local]:5488/pgbench
# insert into t1 values(generate_series(1,100),'amit');
INSERT 0 100
Time: 4.796 ms
➤ psql://thom@[local]:5488/pgbench
# explain select c1 from t1;
ERROR: could not register background process
HINT: You may need to increase max_worker_processes.
Time: 1.659 ms
➤ psql://thom@[local]:5488/pgbench
# show max_worker_processes ;
max_worker_processes
----------------------
8
(1 row)
Time: 0.199 ms
# show parallel_seqscan_degree ;
parallel_seqscan_degree
-------------------------
10
(1 row)
Should I really need to increase max_worker_processes to >= parallel_seqscan_degree? If so, shouldn't there be a hint here along with the error message pointing this out? And should the error be produced when only a *plan* is being requested?
Also, I noticed that where a table is partitioned, the plan isn't parallelised:
# explain select distinct bid from pgbench_accounts;
QUERY PLAN
----------------------------------------------------------------------------------------
HashAggregate (cost=1446639.00..1446643.99 rows=499 width=4)
Group Key: pgbench_accounts.bid
-> Append (cost=0.00..1321639.00 rows=50000001 width=4)
-> Seq Scan on pgbench_accounts (cost=0.00..0.00 rows=1 width=4)
-> Seq Scan on pgbench_accounts_1 (cost=0.00..4279.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_2 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_3 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_4 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_5 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_6 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_7 (cost=0.00..2640.00 rows=100000 width=4)
...
-> Seq Scan on pgbench_accounts_498 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_499 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_500 (cost=0.00..2640.00 rows=100000 width=4)
(504 rows)
# explain select distinct bid from pgbench_accounts;
QUERY PLAN
----------------------------------------------------------------------------------------
HashAggregate (cost=1446639.00..1446643.99 rows=499 width=4)
Group Key: pgbench_accounts.bid
-> Append (cost=0.00..1321639.00 rows=50000001 width=4)
-> Seq Scan on pgbench_accounts (cost=0.00..0.00 rows=1 width=4)
-> Seq Scan on pgbench_accounts_1 (cost=0.00..4279.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_2 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_3 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_4 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_5 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_6 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_7 (cost=0.00..2640.00 rows=100000 width=4)
...
-> Seq Scan on pgbench_accounts_498 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_499 (cost=0.00..2640.00 rows=100000 width=4)
-> Seq Scan on pgbench_accounts_500 (cost=0.00..2640.00 rows=100000 width=4)
(504 rows)
Is this expected?
Thom
pgsql-hackers by date: