Re: Consider low startup cost in add_partial_path
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: James Coleman <jtc331@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Date: 2019-09-28T04:16:05Z
Lists: pgsql-hackers
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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