MIME-Version: 1.0
References: <e9f24286-068e-40cb-a6a9-25a4f938672a@dunslane.net>
 <2005009.1774880253@sss.pgh.pa.us>
 <CAApHDvpOPs-Ywcze5=eyi4s5hO1NM9RA8No20Q=s+0L3LiorHw@mail.gmail.com>
 <2588262.1774911610@sss.pgh.pa.us>
In-Reply-To: <2588262.1774911610@sss.pgh.pa.us>
From: David Rowley <dgrowleyml@gmail.com>
Date: Tue, 31 Mar 2026 12:31:19 +1300
Message-ID: 
 <CAApHDvomHPAZ-_BOt7F7eC+837hFWdh2k9tpEpPhy17wrzBViA@mail.gmail.com>
Subject: Re: scale parallel_tuple_cost by tuple width
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvomHPAZ-_BOt7F7eC%2B837hFWdh2k9tpEpPhy17wrzBViA%40mail.gmail.com>
Precedence: bulk

On Tue, 31 Mar 2026 at 12:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I think it's good to be concerned, but I think this is far from the
worst place to put trust in the width estimates. We also use them in
Memoize, and if we underestimate there, then we might end up with a
Nested Loop -> Memoize plan instead of a Hash or Merge Join. If the
actual Memoize cache hit ratio ends up much worse than expected due to
wider-than-expected tuples, then the chosen plan might be well off
being the optimal one. The execution costs of running a poorly chosen
Nested Loop with a poorly caching Memoize can become quadratic. I
think the parallel vs non-parallel problem is much more linear.

I'm more concerned about the opposite problem of being too liberal and
choosing parallel plans too often, resulting in worker exhaustion and
poorer performance as a result of serially executing parallel plans. I
suppose people could fix that by bumping up the parallel_setup_cost so
that the planner favours reserving parallel workers for plans that get
much bigger benefits from parallelisation.

David