On Mon, Mar 21, 2016 at 11:32 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >> In get_useful_ecs_for_relation, it seems to me that this assertion >> should be removed and replaces by an actual check because even if >> right_ec and left_ec are initialized, we cannot be sure that ec_relids >> contains the relations specified: >> /* >> * restrictinfo->mergeopfamilies != NIL is sufficient to guarantee >> * that left_ec and right_ec will be initialized, per comments in >> * distribute_qual_to_rels, and rel->joininfo should only contain >> ECs >> * where this relation appears on one side or the other. >> */ >> if (bms_is_subset(relids, restrictinfo->right_ec->ec_relids)) >> useful_eclass_list = >> list_append_unique_ptr(useful_eclass_list, >> >> restrictinfo->right_ec); >> else >> { >> Assert(bms_is_subset(relids, >> restrictinfo->left_ec->ec_relids)); >> useful_eclass_list = >> list_append_unique_ptr(useful_eclass_list, >> >> restrictinfo->left_ec); >> } > > An EC covers all the relations covered by all the equivalence members it > contains. In case of mergejoinable clause for outer join, EC may cover just > a single relation whose column appears on either side of the clause. In this > case, bms_is_subset() for a given join relation covering single relation in > EC will be false. So, we have to use bms_overlap() instead of > bms_is_subset(). The caller get_useful_pathkeys_for_rel() extracts the > equivalence member (if any), which is entirely covered by the given > relation. Otherwise, you are correct that we have to convert the assertion > into a condition. I have added comments in get_useful_ecs_for_relation() > explaining, why.
Ah, OK. Thanks for the explanation. This code is fixing the problem for me as well here. (note to self: study more the planner code). -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers