Re: Consider low startup cost in add_partial_path
От | Tomas Vondra |
---|---|
Тема | Re: Consider low startup cost in add_partial_path |
Дата | |
Msg-id | 20190928223741.fllqcjhpv2zdbljr@development обсуждение исходный текст |
Ответ на | Re: Consider low startup cost in add_partial_path (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Consider low startup cost in add_partial_path
|
Список | 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
В списке pgsql-hackers по дате отправления: