On Sat, Jun 18, 2016 at 10:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Sat, Jun 18, 2016 at 8:56 AM, Tom Lane <t...@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. [1] - https://www.postgresql.org/message-id/CAA4eK1KnbezhNWHzUrA0cj1Wh5K1ay-wRQr8SYOdrPt9D80ZFw%40mail.gmail.com With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
