Re: Consider low startup cost in add_partial_path
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: James Coleman <jtc331@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-09-28T22:37:41Z
Lists: pgsql-hackers
On Sat, Sep 28, 2019 at 12:16:05AM -0400, Robert Haas wrote: >On Fri, Sep 27, 2019 at 2:24 PM James Coleman <jtc331@gmail.com> wrote: >> 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. > >I think I just didn't think carefully about the Limit case. > Thanks! In that case I suggest we treat it as a separate patch/fix, independent of the incremental sort patch. I don't want to bury it in that patch series, it's already pretty large. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Consider startup cost as a figure of merit for partial paths.
- 8300d3ad4aa7 19 (unreleased) landed
-
Fix add_partial_path interaction with disabled_nodes
- 6e466e1e839e 19 (unreleased) landed
-
Support parallel joins, and make related improvements.
- 45be99f8cd5d 9.6.0 cited