On Thu, Sep 7, 2017 at 4:32 PM, Antonin Houska <a...@cybertec.at> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > >> On Fri, Sep 1, 2017 at 6:05 PM, Antonin Houska <a...@cybertec.at> wrote: >> > >> > >> > >> > * get_partitioned_child_rels_for_join() >> > >> > I think the Assert() statement is easier to understand inside the loop, see >> > the assert.diff attachment. > >> The assert at the end of function also checks that we have got >> child_rels lists for all the parents passed in. > > Really? I can imagine that some instances of PartitionedChildRelInfo have the > child_rels list empty, while other ones have these lists long enough to > compensate for the empty lists. >
That isn't true. Each child_rels list will at least have one entry. Please see get_partitioned_child_rels(). >> > >> > >> > * have_partkey_equi_join() >> > >> > As the function handles generic join, this comment doesn't seem to me >> > relevant: >> > >> > /* >> > * The equi-join between partition keys is strict if equi-join between >> > * at least one partition key is using a strict operator. See >> > * explanation about outer join reordering identity 3 in >> > * optimizer/README >> > */ >> > strict_op = op_strict(opexpr->opno); >> >> What in that comment is not exactly relevant? > > Basically I don't understand why you mention join reordering here. The join > ordering questions must all have been resolved by the time > have_partkey_equi_join() is called. I am referring to a particular section in README which talks about the relation between strict operator and legal join order. > >> > >> > And I think the function can return true even if strict_op is false for all >> > the operators evaluated in the loop. >> >> I think it does that. Do you have a case where it doesn't? > > Here I refer to this part of the comment above: > > "... if equi-join between at least one partition key is using a strict > operator." > > My understanding of the code (especially match_expr_to_partition_keys) is that > no operator actually needs to be strict as long as each operator involved in > the join matches at least one non-nullable expression on both sides of the > join. I don't think so. A strict operator returns NULL when either of the inputs is NULL. We can not say so for non-strict operators, which may deem NULL and non-NULL arguments as equal, even though that looks insane. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
