In a Parallel Seq Scan (or Parallel Sequential Scan) Postgres uses multiple processes in parallel to read rows from a table. Each process scans a section of the table, page by page sequentially, in the order they are on disk.

The results of these are then combined in a Gather operation.

Parallel sequential scans can be a fast way of getting a high proportion of the rows from large tables. However, fetching a small proportion of rows from a large table is normally far more efficient via an index.

If you use both the ANALYZE and VERBOSE parameters of EXPLAIN, you’ll see per-worker statistics for parallel operations. The leader process details are not shown explicitly, but by default it also contributes to the work.

Parallel Seq Scan fields

• Parent Relationship

• Parallel Aware

• Relation Name

• Schema

• Alias

• Startup Cost

• Total Cost

• Plan Rows

• Plan Width

• Actual Startup Time

• Actual Total Time

• Actual Rows

• Actual Loops

• Output

• Filter

• Rows Removed by Filter

• Shared Hit Blocks

• Shared Read Blocks

• Shared Dirtied Blocks

• Shared Written Blocks

• Local Hit Blocks

• Local Read Blocks

• Local Dirtied Blocks

• Local Written Blocks

• Temp Read Blocks

• Temp Written Blocks

• Shared I/O Read Time

• Shared I/O Write Time

• Local I/O Read Time

• Local I/O Write Time

• Temp I/O Read Time

• Temp I/O Write Time

• Workers

Related operations

• Seq Scan

• Gather

Related official docs

• Parallel Plans

• Query Planning

• Using EXPLAIN

Further reading

• Why isn’t Postgres using my index? — pgMustard

• Increasing max parallel workers per gather — pgMustard

• Row count estimates – pgMustard