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

On Sat, Jun 18, 2016 at 10:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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,

True. I have initially proposed not to change code for adjusting the cost,
rather change test [1]. We can easily change that test.

>
> 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?
>

Sounds sensible. I have noticed that for the cases when there are many
rows to be projected, the projection cost makes reasonable difference which
is quite obvious.

[1] -
https://www.postgresql.org/message-id/CAA4eK1KnbezhNWHzUrA0cj1Wh5K1ay-wRQr8SYOdrPt9D80ZFw%40mail.gmail.com

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com