Hi,
On 2019-12-20 13:58:57 -0500, Tom Lane wrote:
> 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.
+1. I did at some point measure the cost of transferring through a
tuplequeue, and it's quite expensive, compared to local tuple
handoff. Some of that is not intrinsic, and could be fixed - e.g. by
just putting pointers to tuples into the queue, instead of the whole
tuple (but that's hard due to our process model leading to dynamic shm
having differing addresses). What's worse, putting a tuple into a
tuplequeue requires the input slot to be materialized into a HeapTuple
(should probably be MinimalTuple....), which often the input will not
yet be. So I think it'll often be much worse than 10x.
Greetings,
Andres Freund
