Re: scale parallel_tuple_cost by tuple width

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 31 Mar 2026 at 03:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Unfortunately, I'm afraid that this is going to produce mostly
>> "garbage in, garbage out" estimates, because our opinion of how wide
>> tuples-in-flight are is pretty shaky.

> Sure, it's certainly true that there are cases where we don't get the
> width estimate right, but that's not stopped us using them before. So
> why is this case so much more critical?

What I'm concerned about is that the estimated cost's dependency on
tuple width may be much stronger here than it has been in other uses.
That impression might be false, of course.

> For the patch and the analysis: This reminds me of [1], where some
> reverse-engineering of costs from query run-times was done, which
> ended up figuring out what we set APPEND_CPU_COST_MULTIPLIER to. To
> get that for this case would require various tests with different
> tuple widths and ensuring that the costs scale linearly with the
> run-time of the query with the patched version.

Right, I think we really need more test cases to base these magic
numbers on. Such testing would likely also alleviate (or not...)
my discomfort with the width estimates being so poor.

regards, tom lane