Re: Consider low startup cost in add_partial_path
| От | Robert Haas |
|---|---|
| Тема | Re: Consider low startup cost in add_partial_path |
| Дата | |
| Msg-id | CA+Tgmobcht8MM6sxZAxEEe+9aMcEja3OTp9p97gNbcW8ZhzBTw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Consider low startup cost in add_partial_path (James Coleman <jtc331@gmail.com>) |
| Ответы |
Re: Consider low startup cost in add_partial_path
|
| Список | 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
В списке pgsql-hackers по дате отправления: