Re: pgsql: Try again to fix the way the scanjoin_target is used with partia

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Sat, Jun 18, 2016 at 8:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think the two lines in question are just a poorly-thought-through case
>> of premature optimization. If removing them makes the failures go away
>> for me, that's what I plan to do.

> That should make the failure go-away.

Well, it did make the errors go away, but it also made the first test
case in select_parallel.sql change plan, because the parallel plan is
only a whisker cheaper than non-parallel, and the extra charge for the
nonexistent Result node changed the decision. I'm not exactly convinced
that that test case represents behavior we need to preserve, but for
the moment I rejiggered the cost adjustment so the test case stays the
same.

If we keep it like this, we definitely ought to refactor things so that
fewer places are aware of the possibility of the Result getting omitted.
Maybe push that logic into create_projection_path? If we did, we might
not need a separate apply_projection_to_path function at all? Too tired
to decide about it right now.

regards, tom lane