On Sat, Jun 18, 2016 at 10:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapila16@gmail.com> writes: > > On Sat, Jun 18, 2016 at 8:56 AM, Tom Lane <tgl@sss.pgh.pa.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.
