Re: upper planner path-ification

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: upper planner path-ification
Дата
Msg-id CA+TgmobAV3_DS1sXA+PFWkjvX1K-VNiAnMMJrzPfD43g=-4OYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: upper planner path-ification  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: upper planner path-ification  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, May 19, 2015 at 7:19 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Hm.  That's a hangover from when query_planner also gave back a
>  Tom> Plan (singular) rather than a set of Paths.  I don't see any
>  Tom> fundamental reason why we couldn't generalize it to be a list of
>  Tom> potentially useful output orderings rather than just one.  But I'm
>  Tom> a bit concerned about the ensuing growth in planning time; is it
>  Tom> really all that useful?
>
> The planning time growth is a possible concern, yes. The potential gain
> is eliminating one sort step, in the case when the input has a usable
> sorted path but grouping_planner happens not to ask for it (when there's
> more than just a single rollup, the code currently asks for one of the
> sort orders pretty much arbitrarily since it has no real way to know
> otherwise). Whether that would justify it... I don't know. Maybe that's
> one to save for later to see if there's any feedback from actual use.

I kind of doubt that the growth in planning time would be anything too
unreasonable.  We already consider multiple orderings for ordinary
base relations, so it's not very obvious why consideration multiple
orderings for subqueries would be any worse.  If we can arrange to
throw away useless orderings early, as we do in other cases, then any
extra paths we consider have a reasonable chance of being useful.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Thom Brown
Дата:
Сообщение: Re: Per row status during INSERT .. ON CONFLICT UPDATE?