Re: scale parallel_tuple_cost by tuple width
| От | Tom Lane |
|---|---|
| Тема | Re: scale parallel_tuple_cost by tuple width |
| Дата | |
| Msg-id | 2005009.1774880253@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | scale parallel_tuple_cost by tuple width (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: scale parallel_tuple_cost by tuple width
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: