Re: WIP: Upper planner pathification - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: Upper planner pathification
Date
Msg-id 20225.1457534876@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: Upper planner pathification  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: WIP: Upper planner pathification
List 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 by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Proposal: RETURNING primary_key()
Next
From: Mithun Cy
Date:
Subject: Explain [Analyze] produces parallel scan for select Into table statements.