Parallel Sequential Scan is Committed!

Test:

postgres=# set max_parallel_degree = 0;
SET
postgres=# explain analyse select * from foo where val = .4678;
                                              QUERY PLAN
------------------------------------------------------------------------------------------------------
 Seq Scan on foo  (cost=0.00..17402.00 rows=1 width=12) (actual time=200.679..200.679 rows=0 loops=1)
   Filter: (val = '0.4678'::double precision)
   Rows Removed by Filter: 1000000
 Planning time: 0.072 ms
 Execution time: 200.700 ms
(5 rows)

postgres=# set max_parallel_degree = 2;
SET
postgres=# explain analyse select * from foo where val = .4678;
                                                    QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..7960.90 rows=1 width=12) (actual time=84.540..84.540 rows=0 loops=1)
   Number of Workers: 2
   ->  Parallel Seq Scan on foo  (cost=0.00..6960.80 rows=1 width=12) (actual time=52.078..350.967 rows=0 loops=1)
         Filter: (val = '0.4678'::double precision)
         Rows Removed by Filter: 1606084
 Planning time: 0.075 ms
 Execution time: 85.780 ms
(7 rows)

postgres=#

Irre.

Da weiß ich doch wozu ich neuerdings einen 32Kerner habe :slight_smile:

Das eigentlich Tolle daran ist die Basisarchitektur die das ermöglicht. Parallel Seq Scan alleine ist zwar cool, richtig interessant wird es aber erst wenn Teile von Aggregationen parallelisiert werden können. In der Richtung wird wohl noch einiges in der 9.6 zu erwarten sein wenn ich die Diskussionen auf der Hacker Liste richtig verstehe.

Was mich mehr beeindruckt ist, wie flexibel das Extension System ist. Cybertec hat auf Basis der “background worker” eine Extension veröffentlicht, die parallele Aggregation ermöglicht:

http://www.cybertec.at/en/products/agg-parallel-aggregations-postgresql/

Ziemlich beeindruckend.

Genau, ich gebe Dir absolut Recht. Nach dem ersten Satz wollt ich schon auf Schönig sein agg verweisen, aber das hattest Du ja schon :wink:

Wobei ich, soweit ich das vom Schönig verstanden habe, der Meinung bin, daß die Entscheidung über die Worker eher fallen müßte, beim Optimizer. Damit das auch mit Kosten hinterlegt werden kann etc. Aber das sind Details, wichtig ist: wir haben damit eine absolut großartige Infrastruktur, und das, was wir jetzt sehen, ist nur die Spitze des Eisberges an Möglichkeiten. Es bleibt spannend!

Parallele Aggregation und Joins werden auch in der 9.6er drin sein:

http://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/