Re: EXPLAIN of Parallel Append

On Wed, Mar 14, 2018 at 8:58 PM, Jesper Pedersen
<jesper(dot)pedersen(at)redhat(dot)com> wrote:
> Hi,
>
> Given
>
> -- test.sql --
> CREATE TABLE t1 (
> a integer NOT NULL,
> b integer NOT NULL
> ) PARTITION BY HASH (b);
> CREATE TABLE t1_p00 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER
> 0);
> CREATE TABLE t1_p01 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER
> 1);
> CREATE TABLE t1_p02 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER
> 2);
> CREATE TABLE t1_p03 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER
> 3);
> INSERT INTO t1 (SELECT i, i FROM generate_series(1, 1000000) AS i);
> ANALYZE;
> -- test.sql --
>
> Running
>
> EXPLAIN (ANALYZE) SELECT * FROM t1 WHERE a = 5432;
>
> gives
>
> Gather (cost=1000.00..12780.36 rows=4 width=8) (actual time=61.270..61.309
> rows=1 loops=1)
> Workers Planned: 2
> Workers Launched: 2
> -> Parallel Append (cost=0.00..11779.96 rows=4 width=8) (actual
> time=38.915..57.209 rows=0 loops=3)
..
..
> (18 rows)
>
> Parallel Append's ntuples is 1, but given nloops is 3 you end up with the
> slightly confusing "(actual ... *rows=0* loops=3)".
>

The number of rows displayed is total_rows / loops due to which you
are seeing these numbers. This behavior is the same for all parallel
nodes, nothing specific to Parallel Append.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com