Over in the incremental sort patch discussion we found [1] a case where a higher cost plan ends up being chosen because a low startup cost partial path is ignored in favor of a lower total cost partial path and a limit is a applied on top of that which would normal favor the lower startup cost plan.
45be99f8cd5d606086e0a458c9c72910ba8a613d originally added `add_partial_path` with the comment: > Neither do we need to consider startup costs: > parallelism is only used for plans that will be run to completion. > Therefore, this routine is much simpler than add_path: it needs to > consider only pathkeys and total cost. I'm not entirely sure if that is still true or not--I can't easily come up with a scenario in which it's not, but I also can't come up with an inherent reason why such a scenario cannot exist. We could just continue to include this change as part of the incremental sort patch itself, but it seemed worth it to me to break it out for some more targeted discussion, and also include Robert as the initial author of add_partial_path in the hopes that maybe we could retrieve some almost 4-year-old memories on why this was inherently true then, and maybe that would shed some light on whether it's still inherently true. I've attached a patch (by Tomas Vondra, also cc'd) to consider startup cost in add_partial_path, but should we apply the patch we'll also likely need to apply the same kind of change to add_partial_path_precheck. James Coleman [1]: https://www.postgresql.org/message-id/20190720132244.3vgg2uynfpxh3me5%40development
consider-startup-cost-in-add-partial-path_v1.patch
Description: Binary data