Shouldn't cost_append() also scale the partial path's cost?
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t47996psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 24, 2026 at 10:35 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t47996_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t47996_1 && git checkout t47996_1Patchset v1 (message #1) is on t47996_1
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?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
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