Re: WIP: Upper planner pathification

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: Upper planner pathification
Дата
Msg-id 20225.1457534876@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: Upper planner pathification  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: WIP: Upper planner pathification  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> I have a question about Sort path. AFAICS this question wasn't mentioned in
> the upthread discussion.
> We're producing Sort plans in two ways: from explicit Sort paths, and from
> other paths which implicitly assumes sorting (like MergeJoin path).
> Would it be better to produce Sort plan only from explicit Sort path? Thus,
> MergeJoin path would add explicit children Sort paths. That would be more
> unified way.

Meh.  I think the only real effect that would have is to make it slower to
build MergeJoin paths (and in a typical join problem, we build a lot of
those).  The entire point of the Path/Plan distinction is to postpone
until createplan.c any work that's not necessary to arrive at a cost
estimate.  So the way MergeJoinPath works now seems fine to me.

> I ask about this from point of view of my "Partial Sort" patch. The absence
> of implicit sorts would help to make this patch more simple and clean.

There are other implicit sorts besides those.  Admittedly, the efficiency
argument for not making the sort explicit in UniquePath or MergeAppendPath
is a lot weaker than it is for MergeJoin, just because those are less
common path types.  But getting rid of the behavior entirely would be
a lot of work, and I'm not convinced it'd be an improvement.
        regards, tom lane



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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Proposal: RETURNING primary_key()
Следующее
От: Mithun Cy
Дата:
Сообщение: Explain [Analyze] produces parallel scan for select Into table statements.