Andrew Dunstan <andrew@dunslane.net> writes:
> While investigating a performance issue, I found that it was extremely
> difficult to get a parallel plan in some cases due to the fixed
> parallel_tuple_cost. But this cost is not really fixed - it's going to
> be larger for larger tuples. So this proposal adjusts the cost used
> according to how large we expect the results to be.
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. (See get_expr_width and
particularly get_typavgwidth, and note that we only have good
statistics-based numbers for plain Vars not function outputs.)
I agree that it could be useful to have some kind of adjustment here,
but I fear that linear scaling is putting way too much faith in the
quality of the data.
How many cases have you checked with this modified code? Did it
make the plan worse in any cases?
regards, tom lane
