Re: Shouldn't cost_append() also scale the partial path's cost?
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Shouldn't cost_append() also scale the partial path's cost? |
Дата | |
Msg-id | 20230615.110705.118653311686889833.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Shouldn't cost_append() also scale the partial path's cost? (Antonin Houska <ah@cybertec.at>) |
Список | pgsql-hackers |
At Wed, 14 Jun 2023 14:36:54 +0200, Antonin Houska <ah@cybertec.at> wrote in > Like in cost_seqscan(), I'd expect the subpath cost to be divided among > parallel workers. The patch below shows what I mean. Am I right? If I've got it right, the total cost of a partial seqscan path comprises a distributed CPU run cost and an undistributed disk run cost. If we want to adjust for a different worker number, we should only tweak the CPU component of the total cost. By default, if one page contains 100 rows (I guess a moderate ratio), these two costs are balanced at a 1:1 ratio and the CPU run cost and disk run cost in a partial seqscan path is 1:n (n = #workers). If we adjust the run cost in the porposed manner, it adjusts the CPU run cost correctly but in turn the disk run cost gets wrong (by a larger error in this premise). In short, it will get wrong in a different way. Actually it looks strange that rows are adjusted but cost is not, so we might want to add an explanation in this aspect. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: