On Fri, Mar 16, 2018 at 6:06 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think in the patch series this is the questionable patch wherein it > will always add an additional projection path (whether or not it is > required) to all Paths (partial and non-partial) for the scanjoin rel > and then later remove it (if not required) in create_projection_plan. > As you are saying, I also think it might not matter much in the grand > scheme of things and if required we can test it as well, however, I > think it is better if some other people can also share their opinion > on this matter. > > Tom, do you have anything to say?
I forgot to include part of the explanation in my previous email. The reason it has to work this way is that, of course, you can't include the same path in the path list of relation B as you put into the path of relation A; if you do, then you will be in trouble if a later addition to the path list of relation B kicks that path out, because it will get pfree'd, leaving a garbage pointer in the list for A, which you may subsequently referenced. At one point, I tried to solve the problem by sorting the cheapest partial path from the scan/join rel and putting it back into the same pathlist, but that also fails: in some cases, the new path dominates all of the existing paths because it is better-sorted and only very slightly more expensive. So, when you call add_partial_path() for the sort path, all of the previous paths -- including the one the sort path is pointing to as its subpath! -- get pfree'd. So without another relation, and the projection paths, I couldn't get it to where I didn't have to modify paths after creating them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company