min_parallel_table_scan_size

min_parallel_table_scan_size — Sets the minimum amount of table data for a parallel scan. Observed in PG10–19 Beta 3; its last measured boot default is 8 MiB (1024 × 8kB) in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the minimum amount of table data for a parallel scan.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value8kB: Raw unit
Range , Value0 – 715827882: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueQuery Tuning / Planner Cost Constants: Upstream classification
Latest boot value , Value1024: 8 MiB (1024 × 8kB)

Lifecycle

Fact	Value
First observed	PG10
Present in	PG10–19 Beta 3
Removed in	No
Introduction commit	`51ee6f3160d2` — Replace min_parallel_relation_size with two new GUCs.
Commit date	2017-02-15
Discussion	thread 1 · thread 2

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG10–19 Beta 3	`1024`	`8kB`	8 MiB (1024 × 8kB)

How it works

min_parallel_table_scan_size is a planner eligibility floor: parallel scan paths are not considered unless table data estimated to be scanned reaches the configured size.

Crossing this floor does not guarantee a parallel plan. The planner still compares costs, checks parallel safety, and requests workers subject to max_parallel_workers_per_gather and the cluster worker pools.

For a parallel sequential scan, the estimate is normally the whole relation size. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	A higher min_parallel_table_scan_size can reduce parallel startup on short OLTP scans, but confirm that reports and maintenance do not regress. Pigsty’s OLTP/crit value is a policy bias, not a resource limit.
OLAP	Keep the upstream threshold unless small but expensive scans are wrongly excluded. Lowering min_parallel_table_scan_size can raise planning and worker overhead when many queries run concurrently.
Small nodes	Prefer a conservative or higher threshold on a small host where worker startup and memory contention dominate. Coordinate it with max_parallel_workers_per_gather rather than tuning it alone.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`32MB`	different	`32MB`
OLAP	Unmodified	—	—
CRIT	`32MB`	different	`32MB`
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG10–19 Beta 3 = 32MB (dcs); OLAP: PG10–19 Beta 3 unmodified; CRIT: PG10–19 Beta 3 = 32MB (dcs); TINY: PG10–19 Beta 3 unmodified. Advice, pending human review — Editorial inference, pending maintainer review: The OLTP/crit value raises the table eligibility floor to reduce parallel tendency, while OLAP and tiny retain upstream behavior.

Common pitfalls

Assuming the threshold caps actual bytes read; it only controls planner eligibility.
Expecting a parallel plan merely because the size estimate crosses the threshold.
Lowering it without budgeting workers and per-node memory under concurrency.
Comparing the raw numeric value without applying its 8kB block unit.

max_parallel_workers_per_gather · parallel_setup_cost · parallel_tuple_cost · max_parallel_workers · enable_seqscan