From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performa. <pgsql-performance@postgresql.org>
Subject: Re: How to set parallel_tuple_cost
Date: Fri, 20 Dec 2019 13:58:57 -0500
Message-ID: <11002.1576868337@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMkU=1ziWTO_OBmFYkwhdtpc_JrM2Eroip=8vS3CNtgJs6KcoQ@mail.gmail.com>
References: <CAMkU=1ziWTO_OBmFYkwhdtpc_JrM2Eroip=8vS3CNtgJs6KcoQ@mail.gmail.com>
Jeff Janes <jeff.janes@gmail.com> writes:
> The docs for parallel_tuple_cost are quite terse, as the reference section
> of the docs usually are:
> "Sets the planner's estimate of the cost of transferring one tuple from a
> parallel worker process to another process. The default is 0.1."
> If you were take the doc description literally, then the default value
> seems much too high, as it doesn't take 10x the (default) cpu_tuple_cost to
> transfer a tuple up from a parallel worker.
Really? If anything, I'd have thought it might be worse than 10x.
Cross-process communication isn't cheap, at least not according to
my instincts.
> On the other hand, you
> probably don't want a query which consumes 8x the CPU resources just to
> finish only 5% faster (on an otherwise idle server with 8 CPUs). Maybe
> this Amdahl factor is what inspired the high default value?
I think the large value of parallel_setup_cost is what's meant to
discourage that scenario.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, jeff.janes@gmail.com
Subject: Re: How to set parallel_tuple_cost
In-Reply-To: <11002.1576868337@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox