On 7 April 2016 at 08:01, David Rowley <david.row...@2ndquadrant.com> wrote: > On 7 April 2016 at 04:05, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Starting to look at this again. I wonder, now that you have the generic >> caching mechanism for remembering whether join inner sides have been >> proven unique, is it still worth having the is_unique_join field in >> SpecialJoinInfo? It seems like that's creating a separate code path >> for special joins vs. inner joins that may not be buying us much. >> It does potentially save lookups in the unique_rels cache, if you already >> have the SpecialJoinInfo at hand, but I'm not sure what that's worth. > > I quite like that field where it is, as it should make > remove_useless_joins() a bit more efficient, as after a LEFT JOIN is > removed, the previous code would go off and try to make sure all the > joins are unique again, but now we cache that, and save it from having > to bother doing that again, on joins already marked as unique. > > Certainly changing that would mean one less special case in > joinpath.c, as the JOIN_LEFT case can be handle the same as the other > cases, although it looks like probably, if I do change that, then I'd > probably move is_innerrel_unique_for() into analyzejoins.c, and put > the special case for JOIN_LEFT in that function, so that it calls > specialjoin_is_unique_join(), then cache the sjinfo->min_righthand in > the unique_rels cache if the result comes back positive, and in the > non_unique_rels cache if negative... But it seems a bit crazy to go to > the trouble or all that caching, when we can just throw the result in > a struct field in the case of Special Joins. Maybe we could just hide > both the new joinpath.c functions in analyzejoins.c and call it quits. > It's not as if there's no special cases for JOIN_LEFT in that file.
We could also get rid of the SpecialJoinInfo.is_unique_join and just store this as optimal_jointype, where this would be initialised to jointype in make_outerjoininfo(), and then set in mark_unique_joins(). This would simplify the test in get_optimal_jointype(), perhaps if (IS_OUTER_JOIN(jointype)) return sjinfo->optimal_jointype; -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
