Re: select_parallel test fails with nonstandard block size

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: select_parallel test fails with nonstandard block size
Date: 2016-09-15 13:59:57
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> When building with --with-blocksize=16, the select_parallel test fails
> with this difference:

> explain (costs off)
> select sum(parallel_restricted(unique1)) from tenk1
> group by(parallel_restricted(unique1));
> -----------------------------------------------------
> +-------------------------------------------
> HashAggregate
> Group Key: parallel_restricted(unique1)
> - -> Index Only Scan using tenk1_unique1 on tenk1
> -(3 rows)
> + -> Gather
> + Workers Planned: 4
> + -> Parallel Seq Scan on tenk1
> +(5 rows)

> set force_parallel_mode=1;
> explain (costs off)

> We know that different block sizes cause some test failures, mainly
> because of row ordering differences. But this looked a bit different.

I suspect what is happening is that min_parallel_relation_size is
being interpreted differently (because the default is set at 1024
blocks, regardless of what BLCKSZ is) and that's affecting the
cost estimate for the parallel seqscan. The direction of change
seems a bit surprising though; if the table is now half as big
blocks-wise, how did that make the parallel scan look cheaper?
Please step through create_plain_partial_paths and see what
is being done differently.

Possibly we ought to change things so that the default value of
min_parallel_relation_size is a fixed number of bytes rather
than a fixed number of blocks. Not sure though.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-09-15 14:08:34 Re: Printing bitmap objects in the debugger
Previous Message Marco Pfatschbacher 2016-09-15 13:57:55 PATCH: Keep one postmaster monitoring pipe per process