From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | ah(at)cybertec(dot)at |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Shouldn't cost_append() also scale the partial path's cost? |
Date: | 2023-06-15 02:07:05 |
Message-ID: | 20230615.110705.118653311686889833.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 14 Jun 2023 14:36:54 +0200, Antonin Houska <ah(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-06-15 02:22:09 | Re: Do we want a hashset type? |
Previous Message | Masahiko Sawada | 2023-06-15 02:02:07 | Re: Replace (GUC_UNIT_MEMORY | GUC_UNIT_TIME) with GUC_UNIT in guc.c |