Consider startup cost as a figure of merit for partial paths. Previously, the comments stated that there was no purpose to considering startup cost for partial paths, but this is not the case: it's perfectly reasonable to want a fast-start path for a plan that involves a LIMIT (perhaps over an aggregate, so that there is enough data being processed to justify parallel query but yet we don't want all the result rows).
Accordingly, rewrite add_partial_path and add_partial_path_precheck to consider startup costs. This also fixes an independent bug in add_partial_path_precheck: commit e22253467942fdb100087787c3e1e3a8620c54b2 failed to update it to do anything with the new disabled_nodes field. That bug fix is formally separate from the rest of this patch and could be committed separately, but I think it makes more sense to fix both issues together, because then we can (as this commit does) just make add_partial_path_precheck do the cost comparisons in the same way as compare_path_costs_fuzzily, which hopefully reduces the chances of ending up with something that's still incorrect. This patch is based on earlier work on this topic by Tomas Vondra, but I have rewritten a great deal of it. Co-authored-by: Robert Haas <[email protected]> Co-authored-by: Tomas Vondra <[email protected]> Discussion: http://postgr.es/m/ca+tgmobrufbusksboxytgjs1p+mqy4rwctck-d0iauo6-k9...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8300d3ad4aa73dc6beec8dca7d9362dbc21c9a83 Modified Files -------------- src/backend/optimizer/path/joinpath.c | 3 + src/backend/optimizer/util/pathnode.c | 165 +++++++++++++++---------- src/include/optimizer/pathnode.h | 2 +- src/test/regress/expected/incremental_sort.out | 28 +++-- src/test/regress/expected/join_hash.out | 13 +- src/test/regress/sql/join_hash.sql | 10 +- 6 files changed, 133 insertions(+), 88 deletions(-)
