2016-06-08 05:36:22 +02:00
|
|
|
--
|
|
|
|
|
-- PARALLEL
|
|
|
|
|
--
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
create function sp_parallel_restricted(int) returns int as
|
2016-06-17 14:35:47 +02:00
|
|
|
$$begin return $1; end$$ language plpgsql parallel restricted;
|
2016-06-08 05:36:22 +02:00
|
|
|
-- Serializable isolation would disable parallel query, so explicitly use an
|
|
|
|
|
-- arbitrary other level.
|
|
|
|
|
begin isolation level repeatable read;
|
2016-06-18 06:28:51 +02:00
|
|
|
-- encourage use of parallel plans
|
2016-06-08 05:36:22 +02:00
|
|
|
set parallel_setup_cost=0;
|
|
|
|
|
set parallel_tuple_cost=0;
|
Replace min_parallel_relation_size with two new GUCs.
When min_parallel_relation_size was added, the only supported type
of parallel scan was a parallel sequential scan, but there are
pending patches for parallel index scan, parallel index-only scan,
and parallel bitmap heap scan. Those patches introduce two new
types of complications: first, what's relevant is not really the
total size of the relation but the portion of it that we will scan;
and second, index pages and heap pages shouldn't necessarily be
treated in exactly the same way. Typically, the number of index
pages will be quite small, but that doesn't necessarily mean that
a parallel index scan can't pay off.
Therefore, we introduce min_parallel_table_scan_size, which works
out a degree of parallelism for scans based on the number of table
pages that will be scanned (and which is therefore equivalent to
min_parallel_relation_size for parallel sequential scans) and also
min_parallel_index_scan_size which can be used to work out a degree
of parallelism based on the number of index pages that will be
scanned.
Amit Kapila and Robert Haas
Discussion: http://postgr.es/m/CAA4eK1KowGSYYVpd2qPpaPPA5R90r++QwDFbrRECTE9H_HvpOg@mail.gmail.com
Discussion: http://postgr.es/m/CAA4eK1+TnM4pXQbvn7OXqam+k_HZqb0ROZUMxOiL6DWJYCyYow@mail.gmail.com
2017-02-15 19:37:24 +01:00
|
|
|
set min_parallel_table_scan_size=0;
|
2016-06-16 18:00:55 +02:00
|
|
|
set max_parallel_workers_per_gather=4;
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
-- Parallel Append with partial-subplans
|
2016-06-08 05:36:22 +02:00
|
|
|
explain (costs off)
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
select round(avg(aa)), sum(aa) from a_star;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-----------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 3
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Append
|
|
|
|
|
-> Parallel Seq Scan on d_star
|
|
|
|
|
-> Parallel Seq Scan on f_star
|
Improve the heuristic for ordering child paths of a parallel append.
Commit ab7271677 introduced code that attempts to order the child
scans of a Parallel Append node in a way that will minimize execution
time, based on total cost and startup cost. However, it failed to
think hard about what to do when estimated costs are exactly equal;
a case that's particularly likely to occur when comparing on startup
cost. In such a case the ordering of the child paths would be left
to the whims of qsort, an algorithm that isn't even stable.
We can improve matters by applying the rule used elsewhere in the
planner: if total costs are equal, sort on startup cost, and
vice versa. When both cost estimates are exactly equal, rather
than letting qsort do something unpredictable, sort based on the
child paths' relids, which should typically result in sorting in
inheritance order. (The latter provision requires inventing a
qsort-style comparator for bitmapsets, but maybe we'll have use
for that for other reasons in future.)
This results in a few plan changes in the select_parallel test,
but those all look more reasonable than before, when the actual
underlying cost numbers are taken into account.
Discussion: https://postgr.es/m/4944.1515446989@sss.pgh.pa.us
2018-01-09 19:07:52 +01:00
|
|
|
-> Parallel Seq Scan on e_star
|
|
|
|
|
-> Parallel Seq Scan on b_star
|
|
|
|
|
-> Parallel Seq Scan on c_star
|
|
|
|
|
-> Parallel Seq Scan on a_star
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
(11 rows)
|
|
|
|
|
|
2017-12-06 04:40:05 +01:00
|
|
|
select round(avg(aa)), sum(aa) from a_star a1;
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
round | sum
|
|
|
|
|
-------+-----
|
|
|
|
|
14 | 355
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- Parallel Append with both partial and non-partial subplans
|
|
|
|
|
alter table c_star set (parallel_workers = 0);
|
|
|
|
|
alter table d_star set (parallel_workers = 0);
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select round(avg(aa)), sum(aa) from a_star;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-----------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 3
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Append
|
|
|
|
|
-> Seq Scan on d_star
|
|
|
|
|
-> Seq Scan on c_star
|
|
|
|
|
-> Parallel Seq Scan on f_star
|
Improve the heuristic for ordering child paths of a parallel append.
Commit ab7271677 introduced code that attempts to order the child
scans of a Parallel Append node in a way that will minimize execution
time, based on total cost and startup cost. However, it failed to
think hard about what to do when estimated costs are exactly equal;
a case that's particularly likely to occur when comparing on startup
cost. In such a case the ordering of the child paths would be left
to the whims of qsort, an algorithm that isn't even stable.
We can improve matters by applying the rule used elsewhere in the
planner: if total costs are equal, sort on startup cost, and
vice versa. When both cost estimates are exactly equal, rather
than letting qsort do something unpredictable, sort based on the
child paths' relids, which should typically result in sorting in
inheritance order. (The latter provision requires inventing a
qsort-style comparator for bitmapsets, but maybe we'll have use
for that for other reasons in future.)
This results in a few plan changes in the select_parallel test,
but those all look more reasonable than before, when the actual
underlying cost numbers are taken into account.
Discussion: https://postgr.es/m/4944.1515446989@sss.pgh.pa.us
2018-01-09 19:07:52 +01:00
|
|
|
-> Parallel Seq Scan on e_star
|
|
|
|
|
-> Parallel Seq Scan on b_star
|
|
|
|
|
-> Parallel Seq Scan on a_star
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
(11 rows)
|
|
|
|
|
|
2017-12-06 04:40:05 +01:00
|
|
|
select round(avg(aa)), sum(aa) from a_star a2;
|
|
|
|
|
round | sum
|
|
|
|
|
-------+-----
|
|
|
|
|
14 | 355
|
|
|
|
|
(1 row)
|
|
|
|
|
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
-- Parallel Append with only non-partial subplans
|
|
|
|
|
alter table a_star set (parallel_workers = 0);
|
|
|
|
|
alter table b_star set (parallel_workers = 0);
|
|
|
|
|
alter table e_star set (parallel_workers = 0);
|
|
|
|
|
alter table f_star set (parallel_workers = 0);
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select round(avg(aa)), sum(aa) from a_star;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 3
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Append
|
|
|
|
|
-> Seq Scan on d_star
|
|
|
|
|
-> Seq Scan on f_star
|
|
|
|
|
-> Seq Scan on e_star
|
|
|
|
|
-> Seq Scan on b_star
|
|
|
|
|
-> Seq Scan on c_star
|
|
|
|
|
-> Seq Scan on a_star
|
|
|
|
|
(11 rows)
|
|
|
|
|
|
2017-12-06 04:40:05 +01:00
|
|
|
select round(avg(aa)), sum(aa) from a_star a3;
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
round | sum
|
|
|
|
|
-------+-----
|
|
|
|
|
14 | 355
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- Disable Parallel Append
|
|
|
|
|
alter table a_star reset (parallel_workers);
|
|
|
|
|
alter table b_star reset (parallel_workers);
|
|
|
|
|
alter table c_star reset (parallel_workers);
|
|
|
|
|
alter table d_star reset (parallel_workers);
|
|
|
|
|
alter table e_star reset (parallel_workers);
|
|
|
|
|
alter table f_star reset (parallel_workers);
|
|
|
|
|
set enable_parallel_append to off;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select round(avg(aa)), sum(aa) from a_star;
|
2016-06-08 05:36:22 +02:00
|
|
|
QUERY PLAN
|
|
|
|
|
-----------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 1
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Append
|
|
|
|
|
-> Parallel Seq Scan on a_star
|
|
|
|
|
-> Parallel Seq Scan on b_star
|
|
|
|
|
-> Parallel Seq Scan on c_star
|
|
|
|
|
-> Parallel Seq Scan on d_star
|
|
|
|
|
-> Parallel Seq Scan on e_star
|
|
|
|
|
-> Parallel Seq Scan on f_star
|
|
|
|
|
(11 rows)
|
|
|
|
|
|
2017-12-06 04:40:05 +01:00
|
|
|
select round(avg(aa)), sum(aa) from a_star a4;
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
round | sum
|
|
|
|
|
-------+-----
|
|
|
|
|
14 | 355
|
2016-06-08 05:36:22 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
reset enable_parallel_append;
|
2018-02-28 16:56:06 +01:00
|
|
|
-- Parallel Append that runs serially
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
create function sp_test_func() returns setof text as
|
2018-02-28 16:56:06 +01:00
|
|
|
$$ select 'foo'::varchar union all select 'bar'::varchar $$
|
|
|
|
|
language sql stable;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
select sp_test_func() order by 1;
|
|
|
|
|
sp_test_func
|
|
|
|
|
--------------
|
2018-02-28 16:56:06 +01:00
|
|
|
bar
|
|
|
|
|
foo
|
|
|
|
|
(2 rows)
|
|
|
|
|
|
2018-06-20 04:21:42 +02:00
|
|
|
-- Parallel Append is not to be used when the subpath depends on the outer param
|
|
|
|
|
create table part_pa_test(a int, b int) partition by range(a);
|
|
|
|
|
create table part_pa_test_p1 partition of part_pa_test for values from (minvalue) to (0);
|
|
|
|
|
create table part_pa_test_p2 partition of part_pa_test for values from (0) to (maxvalue);
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select (select max((select pa1.b from part_pa_test pa1 where pa1.a = pa2.a)))
|
|
|
|
|
from part_pa_test pa2;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------
|
|
|
|
|
Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 3
|
|
|
|
|
-> Parallel Append
|
|
|
|
|
-> Parallel Seq Scan on part_pa_test_p1 pa2
|
|
|
|
|
-> Parallel Seq Scan on part_pa_test_p2 pa2_1
|
|
|
|
|
SubPlan 2
|
|
|
|
|
-> Result
|
|
|
|
|
SubPlan 1
|
|
|
|
|
-> Append
|
|
|
|
|
-> Seq Scan on part_pa_test_p1 pa1
|
|
|
|
|
Filter: (a = pa2.a)
|
|
|
|
|
-> Seq Scan on part_pa_test_p2 pa1_1
|
|
|
|
|
Filter: (a = pa2.a)
|
|
|
|
|
(14 rows)
|
|
|
|
|
|
|
|
|
|
drop table part_pa_test;
|
2017-11-15 14:17:29 +01:00
|
|
|
-- test with leader participation disabled
|
|
|
|
|
set parallel_leader_participation = off;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1 where stringu1 = 'GRAAAA';
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
---------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (stringu1 = 'GRAAAA'::name)
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1 where stringu1 = 'GRAAAA';
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
15
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- test with leader participation disabled, but no workers available (so
|
|
|
|
|
-- the leader will have to run the plan despite the setting)
|
|
|
|
|
set max_parallel_workers = 0;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1 where stringu1 = 'GRAAAA';
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
---------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (stringu1 = 'GRAAAA'::name)
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1 where stringu1 = 'GRAAAA';
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
15
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
reset max_parallel_workers;
|
|
|
|
|
reset parallel_leader_participation;
|
2016-06-16 18:00:55 +02:00
|
|
|
-- test that parallel_restricted function doesn't run in worker
|
|
|
|
|
alter table tenk1 set (parallel_workers = 4);
|
|
|
|
|
explain (verbose, costs off)
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
select sp_parallel_restricted(unique1) from tenk1
|
2016-06-16 18:00:55 +02:00
|
|
|
where stringu1 = 'GRAAAA' order by 1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
---------------------------------------------------------
|
|
|
|
|
Sort
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
Output: (sp_parallel_restricted(unique1))
|
|
|
|
|
Sort Key: (sp_parallel_restricted(tenk1.unique1))
|
2016-06-16 18:00:55 +02:00
|
|
|
-> Gather
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
Output: sp_parallel_restricted(unique1)
|
2016-06-16 18:00:55 +02:00
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Seq Scan on public.tenk1
|
|
|
|
|
Output: unique1
|
|
|
|
|
Filter: (tenk1.stringu1 = 'GRAAAA'::name)
|
|
|
|
|
(9 rows)
|
|
|
|
|
|
2016-06-17 22:25:02 +02:00
|
|
|
-- test parallel plan when group by expression is in target list.
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select length(stringu1) from tenk1 group by length(stringu1);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
---------------------------------------------------
|
|
|
|
|
Finalize HashAggregate
|
|
|
|
|
Group Key: (length((stringu1)::text))
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial HashAggregate
|
|
|
|
|
Group Key: length((stringu1)::text)
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(7 rows)
|
|
|
|
|
|
|
|
|
|
select length(stringu1) from tenk1 group by length(stringu1);
|
|
|
|
|
length
|
|
|
|
|
--------
|
|
|
|
|
6
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2016-06-18 06:28:51 +02:00
|
|
|
explain (costs off)
|
|
|
|
|
select stringu1, count(*) from tenk1 group by stringu1 order by stringu1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------
|
|
|
|
|
Sort
|
|
|
|
|
Sort Key: stringu1
|
|
|
|
|
-> Finalize HashAggregate
|
|
|
|
|
Group Key: stringu1
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial HashAggregate
|
|
|
|
|
Group Key: stringu1
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(9 rows)
|
|
|
|
|
|
2016-06-17 22:25:02 +02:00
|
|
|
-- test that parallel plan for aggregates is not selected when
|
|
|
|
|
-- target list contains parallel restricted clause.
|
|
|
|
|
explain (costs off)
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
select sum(sp_parallel_restricted(unique1)) from tenk1
|
|
|
|
|
group by(sp_parallel_restricted(unique1));
|
2017-02-19 11:23:59 +01:00
|
|
|
QUERY PLAN
|
|
|
|
|
-------------------------------------------------------------------
|
2016-06-17 22:25:02 +02:00
|
|
|
HashAggregate
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
Group Key: sp_parallel_restricted(unique1)
|
2017-02-19 11:23:59 +01:00
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_unique1 on tenk1
|
|
|
|
|
(5 rows)
|
2016-06-17 22:25:02 +02:00
|
|
|
|
2017-10-27 22:22:39 +02:00
|
|
|
-- test prepared statement
|
|
|
|
|
prepare tenk1_count(integer) As select count((unique1)) from tenk1 where hundred > $1;
|
|
|
|
|
explain (costs off) execute tenk1_count(1);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (hundred > 1)
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
execute tenk1_count(1);
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
9800
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
deallocate tenk1_count;
|
2017-02-15 00:09:47 +01:00
|
|
|
-- test parallel plans for queries containing un-correlated subplans.
|
|
|
|
|
alter table tenk2 set (parallel_workers = 0);
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1 where (two, four) not in
|
|
|
|
|
(select hundred, thousand from tenk2 where thousand > 100);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (NOT (hashed SubPlan 1))
|
|
|
|
|
SubPlan 1
|
|
|
|
|
-> Seq Scan on tenk2
|
|
|
|
|
Filter: (thousand > 100)
|
|
|
|
|
(9 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1 where (two, four) not in
|
|
|
|
|
(select hundred, thousand from tenk2 where thousand > 100);
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
10000
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2017-04-18 21:43:56 +02:00
|
|
|
-- this is not parallel-safe due to use of random() within SubLink's testexpr:
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select * from tenk1 where (unique1 + random())::integer not in
|
|
|
|
|
(select ten from tenk2);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
------------------------------------
|
|
|
|
|
Seq Scan on tenk1
|
|
|
|
|
Filter: (NOT (hashed SubPlan 1))
|
|
|
|
|
SubPlan 1
|
|
|
|
|
-> Seq Scan on tenk2
|
|
|
|
|
(4 rows)
|
|
|
|
|
|
2017-11-16 18:06:14 +01:00
|
|
|
alter table tenk2 reset (parallel_workers);
|
|
|
|
|
-- test parallel plan for a query containing initplan.
|
|
|
|
|
set enable_indexscan = off;
|
|
|
|
|
set enable_indexonlyscan = off;
|
|
|
|
|
set enable_bitmapscan = off;
|
|
|
|
|
alter table tenk2 set (parallel_workers = 2);
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1
|
|
|
|
|
where tenk1.unique1 = (Select max(tenk2.unique1) from tenk2);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
------------------------------------------------------
|
|
|
|
|
Aggregate
|
|
|
|
|
InitPlan 1 (returns $2)
|
|
|
|
|
-> Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 2
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Seq Scan on tenk2
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
Params Evaluated: $2
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (unique1 = $2)
|
|
|
|
|
(12 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1
|
|
|
|
|
where tenk1.unique1 = (Select max(tenk2.unique1) from tenk2);
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
1
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
reset enable_indexscan;
|
|
|
|
|
reset enable_indexonlyscan;
|
|
|
|
|
reset enable_bitmapscan;
|
2017-02-15 00:09:47 +01:00
|
|
|
alter table tenk2 reset (parallel_workers);
|
2017-02-15 19:53:24 +01:00
|
|
|
-- test parallel index scans.
|
|
|
|
|
set enable_seqscan to off;
|
|
|
|
|
set enable_bitmapscan to off;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count((unique1)) from tenk1 where hundred > 1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Index Scan using tenk1_hundred on tenk1
|
|
|
|
|
Index Cond: (hundred > 1)
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select count((unique1)) from tenk1 where hundred > 1;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
9800
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2017-02-19 11:23:59 +01:00
|
|
|
-- test parallel index-only scans.
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1 where thousand > 95;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_thous_tenthous on tenk1
|
|
|
|
|
Index Cond: (thousand > 95)
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1 where thousand > 95;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
9040
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2017-08-31 19:15:54 +02:00
|
|
|
-- test rescan cases too
|
|
|
|
|
set enable_material = false;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select * from
|
|
|
|
|
(select count(unique1) from tenk1 where hundred > 10) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------------------
|
|
|
|
|
Nested Loop Left Join
|
|
|
|
|
-> Values Scan on "*VALUES*"
|
|
|
|
|
-> Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Index Scan using tenk1_hundred on tenk1
|
|
|
|
|
Index Cond: (hundred > 10)
|
|
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
|
|
select * from
|
|
|
|
|
(select count(unique1) from tenk1 where hundred > 10) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true;
|
|
|
|
|
count | x
|
|
|
|
|
-------+---
|
|
|
|
|
8900 | 1
|
|
|
|
|
8900 | 2
|
|
|
|
|
8900 | 3
|
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select * from
|
|
|
|
|
(select count(*) from tenk1 where thousand > 99) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------------------------------
|
|
|
|
|
Nested Loop Left Join
|
|
|
|
|
-> Values Scan on "*VALUES*"
|
|
|
|
|
-> Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_thous_tenthous on tenk1
|
|
|
|
|
Index Cond: (thousand > 99)
|
|
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
|
|
select * from
|
|
|
|
|
(select count(*) from tenk1 where thousand > 99) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true;
|
|
|
|
|
count | x
|
|
|
|
|
-------+---
|
|
|
|
|
9000 | 1
|
|
|
|
|
9000 | 2
|
|
|
|
|
9000 | 3
|
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
|
|
reset enable_material;
|
2017-02-15 19:53:24 +01:00
|
|
|
reset enable_seqscan;
|
|
|
|
|
reset enable_bitmapscan;
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
-- test parallel bitmap heap scan.
|
|
|
|
|
set enable_seqscan to off;
|
|
|
|
|
set enable_indexscan to off;
|
2017-04-06 22:36:54 +02:00
|
|
|
set enable_hashjoin to off;
|
|
|
|
|
set enable_mergejoin to off;
|
|
|
|
|
set enable_material to off;
|
2017-04-06 23:21:39 +02:00
|
|
|
-- test prefetching, if the platform allows it
|
|
|
|
|
DO $$
|
|
|
|
|
BEGIN
|
|
|
|
|
SET effective_io_concurrency = 50;
|
|
|
|
|
EXCEPTION WHEN invalid_parameter_value THEN
|
|
|
|
|
END $$;
|
2017-04-06 22:36:54 +02:00
|
|
|
set work_mem='64kB'; --set small work mem to force lossy pages
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
explain (costs off)
|
2017-04-06 22:36:54 +02:00
|
|
|
select count(*) from tenk1, tenk2 where tenk1.hundred > 1 and tenk2.thousand=0;
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
QUERY PLAN
|
|
|
|
|
------------------------------------------------------------
|
2017-04-06 22:36:54 +02:00
|
|
|
Aggregate
|
|
|
|
|
-> Nested Loop
|
|
|
|
|
-> Seq Scan on tenk2
|
|
|
|
|
Filter: (thousand = 0)
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
-> Parallel Bitmap Heap Scan on tenk1
|
|
|
|
|
Recheck Cond: (hundred > 1)
|
|
|
|
|
-> Bitmap Index Scan on tenk1_hundred
|
|
|
|
|
Index Cond: (hundred > 1)
|
2017-04-06 22:36:54 +02:00
|
|
|
(10 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1, tenk2 where tenk1.hundred > 1 and tenk2.thousand=0;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
98000
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
create table bmscantest (a int, t text);
|
|
|
|
|
insert into bmscantest select r, 'fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo' FROM generate_series(1,100000) r;
|
|
|
|
|
create index i_bmtest ON bmscantest(a);
|
|
|
|
|
select count(*) from bmscantest where a>1;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
99999
|
|
|
|
|
(1 row)
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
|
2017-12-19 18:21:56 +01:00
|
|
|
-- test accumulation of stats for parallel nodes
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
reset enable_seqscan;
|
2017-12-19 18:21:56 +01:00
|
|
|
alter table tenk2 set (parallel_workers = 0);
|
|
|
|
|
explain (analyze, timing off, summary off, costs off)
|
|
|
|
|
select count(*) from tenk1, tenk2 where tenk1.hundred > 1
|
|
|
|
|
and tenk2.thousand=0;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------------------
|
|
|
|
|
Aggregate (actual rows=1 loops=1)
|
|
|
|
|
-> Nested Loop (actual rows=98000 loops=1)
|
|
|
|
|
-> Seq Scan on tenk2 (actual rows=10 loops=1)
|
|
|
|
|
Filter: (thousand = 0)
|
|
|
|
|
Rows Removed by Filter: 9990
|
|
|
|
|
-> Gather (actual rows=9800 loops=10)
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
Workers Launched: 4
|
|
|
|
|
-> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50)
|
|
|
|
|
Filter: (hundred > 1)
|
|
|
|
|
Rows Removed by Filter: 40
|
|
|
|
|
(11 rows)
|
|
|
|
|
|
|
|
|
|
alter table tenk2 reset (parallel_workers);
|
|
|
|
|
reset work_mem;
|
|
|
|
|
create function explain_parallel_sort_stats() returns setof text
|
|
|
|
|
language plpgsql as
|
|
|
|
|
$$
|
|
|
|
|
declare ln text;
|
|
|
|
|
begin
|
|
|
|
|
for ln in
|
|
|
|
|
explain (analyze, timing off, summary off, costs off)
|
|
|
|
|
select * from
|
|
|
|
|
(select ten from tenk1 where ten < 100 order by ten) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true
|
|
|
|
|
loop
|
|
|
|
|
ln := regexp_replace(ln, 'Memory: \S*', 'Memory: xxx');
|
|
|
|
|
return next ln;
|
|
|
|
|
end loop;
|
|
|
|
|
end;
|
|
|
|
|
$$;
|
|
|
|
|
select * from explain_parallel_sort_stats();
|
|
|
|
|
explain_parallel_sort_stats
|
|
|
|
|
--------------------------------------------------------------------------
|
|
|
|
|
Nested Loop Left Join (actual rows=30000 loops=1)
|
|
|
|
|
-> Values Scan on "*VALUES*" (actual rows=3 loops=1)
|
|
|
|
|
-> Gather Merge (actual rows=10000 loops=3)
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
Workers Launched: 4
|
|
|
|
|
-> Sort (actual rows=2000 loops=15)
|
|
|
|
|
Sort Key: tenk1.ten
|
|
|
|
|
Sort Method: quicksort Memory: xxx
|
|
|
|
|
Worker 0: Sort Method: quicksort Memory: xxx
|
|
|
|
|
Worker 1: Sort Method: quicksort Memory: xxx
|
|
|
|
|
Worker 2: Sort Method: quicksort Memory: xxx
|
|
|
|
|
Worker 3: Sort Method: quicksort Memory: xxx
|
|
|
|
|
-> Parallel Seq Scan on tenk1 (actual rows=2000 loops=15)
|
|
|
|
|
Filter: (ten < 100)
|
|
|
|
|
(14 rows)
|
|
|
|
|
|
Support parallel bitmap heap scans.
The index is scanned by a single process, but then all cooperating
processes can iterate jointly over the resulting set of heap blocks.
In the future, we might also want to support using a parallel bitmap
index scan to set up for a parallel bitmap heap scan, but that's a
job for another day.
Dilip Kumar, with some corrections and cosmetic changes by me. The
larger patch set of which this is a part has been reviewed and tested
by (at least) Andres Freund, Amit Khandekar, Tushar Ahuja, Rafia
Sabih, Haribabu Kommi, Thomas Munro, and me.
Discussion: http://postgr.es/m/CAFiTN-uc4=0WxRGfCzs-xfkMYcSEWUC-Fon6thkJGjkh9i=13A@mail.gmail.com
2017-03-08 18:05:43 +01:00
|
|
|
reset enable_indexscan;
|
2017-04-06 22:36:54 +02:00
|
|
|
reset enable_hashjoin;
|
|
|
|
|
reset enable_mergejoin;
|
|
|
|
|
reset enable_material;
|
|
|
|
|
reset effective_io_concurrency;
|
|
|
|
|
drop table bmscantest;
|
2017-12-19 18:21:56 +01:00
|
|
|
drop function explain_parallel_sort_stats();
|
2017-03-07 17:49:49 +01:00
|
|
|
-- test parallel merge join path.
|
|
|
|
|
set enable_hashjoin to off;
|
|
|
|
|
set enable_nestloop to off;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1, tenk2 where tenk1.unique1 = tenk2.unique1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Merge Join
|
|
|
|
|
Merge Cond: (tenk1.unique1 = tenk2.unique1)
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_unique1 on tenk1
|
|
|
|
|
-> Index Only Scan using tenk2_unique1 on tenk2
|
|
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1, tenk2 where tenk1.unique1 = tenk2.unique1;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
10000
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
reset enable_hashjoin;
|
|
|
|
|
reset enable_nestloop;
|
2017-08-15 00:21:26 +02:00
|
|
|
-- test gather merge
|
|
|
|
|
set enable_hashagg = false;
|
2017-03-09 13:40:36 +01:00
|
|
|
explain (costs off)
|
2017-08-15 00:21:26 +02:00
|
|
|
select count(*) from tenk1 group by twenty;
|
2017-03-09 13:40:36 +01:00
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------
|
|
|
|
|
Finalize GroupAggregate
|
2017-08-15 00:21:26 +02:00
|
|
|
Group Key: twenty
|
2017-03-09 13:40:36 +01:00
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial GroupAggregate
|
2017-08-15 00:21:26 +02:00
|
|
|
Group Key: twenty
|
2017-03-09 13:40:36 +01:00
|
|
|
-> Sort
|
2017-08-15 00:21:26 +02:00
|
|
|
Sort Key: twenty
|
2017-03-09 13:40:36 +01:00
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(9 rows)
|
|
|
|
|
|
2017-08-15 00:21:26 +02:00
|
|
|
select count(*) from tenk1 group by twenty;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
(20 rows)
|
|
|
|
|
|
2017-11-13 22:33:56 +01:00
|
|
|
--test expressions in targetlist are pushed down for gather merge
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
create function sp_simple_func(var1 integer) returns integer
|
2017-11-13 22:33:56 +01:00
|
|
|
as $$
|
|
|
|
|
begin
|
|
|
|
|
return var1 + 10;
|
|
|
|
|
end;
|
|
|
|
|
$$ language plpgsql PARALLEL SAFE;
|
|
|
|
|
explain (costs off, verbose)
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
select ten, sp_simple_func(ten) from tenk1 where ten < 100 order by ten;
|
2017-11-13 22:33:56 +01:00
|
|
|
QUERY PLAN
|
|
|
|
|
-----------------------------------------------------
|
|
|
|
|
Gather Merge
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
Output: ten, (sp_simple_func(ten))
|
2017-11-13 22:33:56 +01:00
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Result
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
Output: ten, sp_simple_func(ten)
|
2017-11-13 22:33:56 +01:00
|
|
|
-> Sort
|
|
|
|
|
Output: ten
|
|
|
|
|
Sort Key: tenk1.ten
|
|
|
|
|
-> Parallel Seq Scan on public.tenk1
|
|
|
|
|
Output: ten
|
|
|
|
|
Filter: (tenk1.ten < 100)
|
|
|
|
|
(11 rows)
|
|
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
drop function sp_simple_func(integer);
|
2018-06-21 16:58:42 +02:00
|
|
|
-- test handling of SRFs in targetlist (bug in 10.0)
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*), generate_series(1,2) from tenk1 group by twenty;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
ProjectSet
|
|
|
|
|
-> Finalize GroupAggregate
|
|
|
|
|
Group Key: twenty
|
|
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial GroupAggregate
|
|
|
|
|
Group Key: twenty
|
|
|
|
|
-> Sort
|
|
|
|
|
Sort Key: twenty
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(10 rows)
|
|
|
|
|
|
|
|
|
|
select count(*), generate_series(1,2) from tenk1 group by twenty;
|
|
|
|
|
count | generate_series
|
|
|
|
|
-------+-----------------
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
500 | 1
|
|
|
|
|
500 | 2
|
|
|
|
|
(40 rows)
|
|
|
|
|
|
2017-11-15 14:17:29 +01:00
|
|
|
-- test gather merge with parallel leader participation disabled
|
|
|
|
|
set parallel_leader_participation = off;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select count(*) from tenk1 group by twenty;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------
|
|
|
|
|
Finalize GroupAggregate
|
|
|
|
|
Group Key: twenty
|
|
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial GroupAggregate
|
|
|
|
|
Group Key: twenty
|
|
|
|
|
-> Sort
|
|
|
|
|
Sort Key: twenty
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(9 rows)
|
|
|
|
|
|
|
|
|
|
select count(*) from tenk1 group by twenty;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
500
|
|
|
|
|
(20 rows)
|
|
|
|
|
|
|
|
|
|
reset parallel_leader_participation;
|
2017-08-30 15:59:23 +02:00
|
|
|
--test rescan behavior of gather merge
|
|
|
|
|
set enable_material = false;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select * from
|
|
|
|
|
(select string4, count(unique2)
|
|
|
|
|
from tenk1 group by string4 order by string4) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
Nested Loop Left Join
|
|
|
|
|
-> Values Scan on "*VALUES*"
|
|
|
|
|
-> Finalize GroupAggregate
|
|
|
|
|
Group Key: tenk1.string4
|
|
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial GroupAggregate
|
|
|
|
|
Group Key: tenk1.string4
|
|
|
|
|
-> Sort
|
|
|
|
|
Sort Key: tenk1.string4
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(11 rows)
|
|
|
|
|
|
|
|
|
|
select * from
|
|
|
|
|
(select string4, count(unique2)
|
|
|
|
|
from tenk1 group by string4 order by string4) ss
|
|
|
|
|
right join (values (1),(2),(3)) v(x) on true;
|
|
|
|
|
string4 | count | x
|
|
|
|
|
---------+-------+---
|
|
|
|
|
AAAAxx | 2500 | 1
|
|
|
|
|
HHHHxx | 2500 | 1
|
|
|
|
|
OOOOxx | 2500 | 1
|
|
|
|
|
VVVVxx | 2500 | 1
|
|
|
|
|
AAAAxx | 2500 | 2
|
|
|
|
|
HHHHxx | 2500 | 2
|
|
|
|
|
OOOOxx | 2500 | 2
|
|
|
|
|
VVVVxx | 2500 | 2
|
|
|
|
|
AAAAxx | 2500 | 3
|
|
|
|
|
HHHHxx | 2500 | 3
|
|
|
|
|
OOOOxx | 2500 | 3
|
|
|
|
|
VVVVxx | 2500 | 3
|
|
|
|
|
(12 rows)
|
|
|
|
|
|
|
|
|
|
reset enable_material;
|
2017-08-29 19:12:23 +02:00
|
|
|
reset enable_hashagg;
|
2017-11-14 21:03:55 +01:00
|
|
|
-- check parallelized int8 aggregate (bug #14897)
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select avg(unique1::int8) from tenk1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-------------------------------------------------------------------------
|
|
|
|
|
Finalize Aggregate
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Partial Aggregate
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_unique1 on tenk1
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
select avg(unique1::int8) from tenk1;
|
|
|
|
|
avg
|
|
|
|
|
-----------------------
|
|
|
|
|
4999.5000000000000000
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2017-08-29 19:12:23 +02:00
|
|
|
-- gather merge test with a LIMIT
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select fivethous from tenk1 order by fivethous limit 4;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------
|
|
|
|
|
Limit
|
|
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Sort
|
|
|
|
|
Sort Key: fivethous
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select fivethous from tenk1 order by fivethous limit 4;
|
|
|
|
|
fivethous
|
|
|
|
|
-----------
|
|
|
|
|
0
|
|
|
|
|
0
|
|
|
|
|
1
|
|
|
|
|
1
|
|
|
|
|
(4 rows)
|
|
|
|
|
|
2017-08-15 00:21:26 +02:00
|
|
|
-- gather merge test with 0 worker
|
|
|
|
|
set max_parallel_workers = 0;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select string4 from tenk1 order by string4 limit 5;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------
|
|
|
|
|
Limit
|
|
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Sort
|
|
|
|
|
Sort Key: string4
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select string4 from tenk1 order by string4 limit 5;
|
|
|
|
|
string4
|
|
|
|
|
---------
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
(5 rows)
|
2017-03-09 13:40:36 +01:00
|
|
|
|
2017-11-15 14:17:29 +01:00
|
|
|
-- gather merge test with 0 workers, with parallel leader
|
|
|
|
|
-- participation disabled (the leader will have to run the plan
|
|
|
|
|
-- despite the setting)
|
|
|
|
|
set parallel_leader_participation = off;
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select string4 from tenk1 order by string4 limit 5;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------
|
|
|
|
|
Limit
|
|
|
|
|
-> Gather Merge
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Sort
|
|
|
|
|
Sort Key: string4
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
select string4 from tenk1 order by string4 limit 5;
|
|
|
|
|
string4
|
|
|
|
|
---------
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
AAAAxx
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
reset parallel_leader_participation;
|
2017-08-15 00:21:26 +02:00
|
|
|
reset max_parallel_workers;
|
2017-08-25 02:42:49 +02:00
|
|
|
SAVEPOINT settings;
|
|
|
|
|
SET LOCAL force_parallel_mode = 1;
|
2016-06-08 05:36:22 +02:00
|
|
|
explain (costs off)
|
|
|
|
|
select stringu1::int2 from tenk1 where unique1 = 1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-----------------------------------------------
|
|
|
|
|
Gather
|
|
|
|
|
Workers Planned: 1
|
|
|
|
|
Single Copy: true
|
|
|
|
|
-> Index Scan using tenk1_unique1 on tenk1
|
|
|
|
|
Index Cond: (unique1 = 1)
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
2017-08-25 02:42:49 +02:00
|
|
|
ROLLBACK TO SAVEPOINT settings;
|
|
|
|
|
-- exercise record typmod remapping between backends
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE FUNCTION make_record(n int)
|
2017-08-25 02:42:49 +02:00
|
|
|
RETURNS RECORD LANGUAGE plpgsql PARALLEL SAFE AS
|
|
|
|
|
$$
|
|
|
|
|
BEGIN
|
|
|
|
|
RETURN CASE n
|
|
|
|
|
WHEN 1 THEN ROW(1)
|
|
|
|
|
WHEN 2 THEN ROW(1, 2)
|
|
|
|
|
WHEN 3 THEN ROW(1, 2, 3)
|
|
|
|
|
WHEN 4 THEN ROW(1, 2, 3, 4)
|
|
|
|
|
ELSE ROW(1, 2, 3, 4, 5)
|
|
|
|
|
END;
|
|
|
|
|
END;
|
|
|
|
|
$$;
|
|
|
|
|
SAVEPOINT settings;
|
|
|
|
|
SET LOCAL force_parallel_mode = 1;
|
|
|
|
|
SELECT make_record(x) FROM (SELECT generate_series(1, 5) x) ss ORDER BY x;
|
|
|
|
|
make_record
|
|
|
|
|
-------------
|
|
|
|
|
(1)
|
|
|
|
|
(1,2)
|
|
|
|
|
(1,2,3)
|
|
|
|
|
(1,2,3,4)
|
|
|
|
|
(1,2,3,4,5)
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
ROLLBACK TO SAVEPOINT settings;
|
|
|
|
|
DROP function make_record(n int);
|
2017-10-29 08:28:40 +01:00
|
|
|
-- test the sanity of parallel query after the active role is dropped.
|
|
|
|
|
drop role if exists regress_parallel_worker;
|
|
|
|
|
NOTICE: role "regress_parallel_worker" does not exist, skipping
|
|
|
|
|
create role regress_parallel_worker;
|
|
|
|
|
set role regress_parallel_worker;
|
|
|
|
|
reset session authorization;
|
|
|
|
|
drop role regress_parallel_worker;
|
|
|
|
|
set force_parallel_mode = 1;
|
|
|
|
|
select count(*) from tenk1;
|
|
|
|
|
count
|
|
|
|
|
-------
|
|
|
|
|
10000
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
reset force_parallel_mode;
|
|
|
|
|
reset role;
|
2018-09-04 06:36:09 +02:00
|
|
|
-- Window function calculation can't be pushed to workers.
|
|
|
|
|
explain (costs off, verbose)
|
|
|
|
|
select count(*) from tenk1 a where (unique1, two) in
|
|
|
|
|
(select unique1, row_number() over() from tenk1 b);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------------------------------------------------
|
|
|
|
|
Aggregate
|
|
|
|
|
Output: count(*)
|
|
|
|
|
-> Hash Semi Join
|
|
|
|
|
Hash Cond: ((a.unique1 = b.unique1) AND (a.two = (row_number() OVER (?))))
|
|
|
|
|
-> Gather
|
|
|
|
|
Output: a.unique1, a.two
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Seq Scan on public.tenk1 a
|
|
|
|
|
Output: a.unique1, a.two
|
|
|
|
|
-> Hash
|
|
|
|
|
Output: b.unique1, (row_number() OVER (?))
|
|
|
|
|
-> WindowAgg
|
|
|
|
|
Output: b.unique1, row_number() OVER (?)
|
|
|
|
|
-> Gather
|
|
|
|
|
Output: b.unique1
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_unique1 on public.tenk1 b
|
|
|
|
|
Output: b.unique1
|
|
|
|
|
(18 rows)
|
|
|
|
|
|
2018-09-14 06:06:30 +02:00
|
|
|
-- LIMIT/OFFSET within sub-selects can't be pushed to workers.
|
|
|
|
|
explain (costs off)
|
|
|
|
|
select * from tenk1 a where two in
|
|
|
|
|
(select two from tenk1 b where stringu1 like '%AAAA' limit 3);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
---------------------------------------------------------------
|
|
|
|
|
Hash Semi Join
|
|
|
|
|
Hash Cond: (a.two = b.two)
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Seq Scan on tenk1 a
|
|
|
|
|
-> Hash
|
|
|
|
|
-> Limit
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Seq Scan on tenk1 b
|
|
|
|
|
Filter: (stringu1 ~~ '%AAAA'::text)
|
|
|
|
|
(11 rows)
|
|
|
|
|
|
2017-04-06 22:44:48 +02:00
|
|
|
-- to increase the parallel query test coverage
|
2017-08-25 02:42:49 +02:00
|
|
|
SAVEPOINT settings;
|
|
|
|
|
SET LOCAL force_parallel_mode = 1;
|
2017-04-06 22:44:48 +02:00
|
|
|
EXPLAIN (analyze, timing off, summary off, costs off) SELECT * FROM tenk1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-------------------------------------------------------------
|
|
|
|
|
Gather (actual rows=10000 loops=1)
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
Workers Launched: 4
|
|
|
|
|
-> Parallel Seq Scan on tenk1 (actual rows=2000 loops=5)
|
|
|
|
|
(4 rows)
|
|
|
|
|
|
2017-08-25 02:42:49 +02:00
|
|
|
ROLLBACK TO SAVEPOINT settings;
|
2016-08-22 18:00:00 +02:00
|
|
|
-- provoke error in worker
|
2017-08-25 02:42:49 +02:00
|
|
|
SAVEPOINT settings;
|
|
|
|
|
SET LOCAL force_parallel_mode = 1;
|
2016-08-22 18:00:00 +02:00
|
|
|
select stringu1::int2 from tenk1 where unique1 = 1;
|
2018-07-22 23:58:01 +02:00
|
|
|
ERROR: invalid input syntax for type smallint: "BAAAAA"
|
2016-08-22 18:00:00 +02:00
|
|
|
CONTEXT: parallel worker
|
2017-08-25 02:42:49 +02:00
|
|
|
ROLLBACK TO SAVEPOINT settings;
|
Let Parallel Append over simple UNION ALL have partial subpaths.
A simple UNION ALL gets flattened into an appendrel of subquery
RTEs, but up until now it's been impossible for the appendrel to use
the partial paths for the subqueries, so we can implement the
appendrel as a Parallel Append but only one with non-partial paths
as children.
There are three separate obstacles to removing that limitation.
First, when planning a subquery, propagate any partial paths to the
final_rel so that they are potentially visible to outer query levels
(but not if they have initPlans attached, because that wouldn't be
safe). Second, after planning a subquery, propagate any partial paths
for the final_rel to the subquery RTE in the outer query level in the
same way we do for non-partial paths. Third, teach finalize_plan() to
account for the possibility that the fake parameter we use for rescan
signalling when the plan contains a Gather (Merge) node may be
propagated from an outer query level.
Patch by me, reviewed and tested by Amit Khandekar, Rajkumar
Raghuwanshi, and Ashutosh Bapat. Test cases based on examples by
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CA+Tgmoa6L9A1nNCk3aTDVZLZ4KkHDn1+tm7mFyFvP+uQPS7bAg@mail.gmail.com
2018-03-13 21:34:08 +01:00
|
|
|
-- test interaction with set-returning functions
|
|
|
|
|
SAVEPOINT settings;
|
|
|
|
|
-- multiple subqueries under a single Gather node
|
|
|
|
|
-- must set parallel_setup_cost > 0 to discourage multiple Gather nodes
|
|
|
|
|
SET LOCAL parallel_setup_cost = 10;
|
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
|
SELECT unique1 FROM tenk1 WHERE fivethous = tenthous + 1
|
|
|
|
|
UNION ALL
|
|
|
|
|
SELECT unique1 FROM tenk1 WHERE fivethous = tenthous + 1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
----------------------------------------------------
|
|
|
|
|
Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Append
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (fivethous = (tenthous + 1))
|
|
|
|
|
-> Parallel Seq Scan on tenk1 tenk1_1
|
|
|
|
|
Filter: (fivethous = (tenthous + 1))
|
|
|
|
|
(7 rows)
|
|
|
|
|
|
|
|
|
|
ROLLBACK TO SAVEPOINT settings;
|
|
|
|
|
-- can't use multiple subqueries under a single Gather node due to initPlans
|
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
|
SELECT unique1 FROM tenk1 WHERE fivethous =
|
|
|
|
|
(SELECT unique1 FROM tenk1 WHERE fivethous = 1 LIMIT 1)
|
|
|
|
|
UNION ALL
|
|
|
|
|
SELECT unique1 FROM tenk1 WHERE fivethous =
|
|
|
|
|
(SELECT unique2 FROM tenk1 WHERE fivethous = 1 LIMIT 1)
|
|
|
|
|
ORDER BY 1;
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
--------------------------------------------------------------------
|
|
|
|
|
Sort
|
|
|
|
|
Sort Key: tenk1.unique1
|
|
|
|
|
-> Append
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
Params Evaluated: $1
|
|
|
|
|
InitPlan 1 (returns $1)
|
|
|
|
|
-> Limit
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Seq Scan on tenk1 tenk1_2
|
|
|
|
|
Filter: (fivethous = 1)
|
|
|
|
|
-> Parallel Seq Scan on tenk1
|
|
|
|
|
Filter: (fivethous = $1)
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
Params Evaluated: $3
|
|
|
|
|
InitPlan 2 (returns $3)
|
|
|
|
|
-> Limit
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Seq Scan on tenk1 tenk1_3
|
|
|
|
|
Filter: (fivethous = 1)
|
|
|
|
|
-> Parallel Seq Scan on tenk1 tenk1_1
|
|
|
|
|
Filter: (fivethous = $3)
|
|
|
|
|
(25 rows)
|
|
|
|
|
|
|
|
|
|
-- test interaction with SRFs
|
|
|
|
|
SELECT * FROM information_schema.foreign_data_wrapper_options
|
|
|
|
|
ORDER BY 1, 2, 3;
|
|
|
|
|
foreign_data_wrapper_catalog | foreign_data_wrapper_name | option_name | option_value
|
|
|
|
|
------------------------------+---------------------------+-------------+--------------
|
|
|
|
|
(0 rows)
|
|
|
|
|
|
2018-04-25 21:14:14 +02:00
|
|
|
-- test interation between subquery and partial_paths
|
|
|
|
|
SET LOCAL min_parallel_table_scan_size TO 0;
|
|
|
|
|
CREATE VIEW tenk1_vw_sec WITH (security_barrier) AS SELECT * FROM tenk1;
|
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
|
SELECT 1 FROM tenk1_vw_sec WHERE EXISTS (SELECT 1 WHERE unique1 = 0);
|
|
|
|
|
QUERY PLAN
|
|
|
|
|
-------------------------------------------------------------------
|
|
|
|
|
Subquery Scan on tenk1_vw_sec
|
|
|
|
|
Filter: (alternatives: SubPlan 1 or hashed SubPlan 2)
|
|
|
|
|
-> Gather
|
|
|
|
|
Workers Planned: 4
|
|
|
|
|
-> Parallel Index Only Scan using tenk1_unique1 on tenk1
|
|
|
|
|
SubPlan 1
|
|
|
|
|
-> Result
|
|
|
|
|
One-Time Filter: (tenk1_vw_sec.unique1 = 0)
|
|
|
|
|
SubPlan 2
|
|
|
|
|
-> Result
|
|
|
|
|
(10 rows)
|
|
|
|
|
|
2016-06-08 05:36:22 +02:00
|
|
|
rollback;
|
