On Tue, 31 Mar 2026 at 12:00, Tom Lane <[email protected]> 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
