对PostgreSQL源代码中的is_pushed_down的理解

在PostgreSQL的源代码中，有如下调用关系：

query_planner
  -->generate_base_implied_equalities
        -->generate_base_implied_qualities_const
             -->process_implied_equality
                   -->distribute_qual_to_rels

distribute_qual_to_rels的函数定义如下：

static void

distribute_qual_to_rels(PlannerInfo *root, Node *clause,

                        bool is_deduced,

                        bool below_outer_join,

                        JoinType jointype,

                        Relids qualscope,

                        Relids ojscope,

                        Relids outerjoin_nonnullable)

{

    ...

    /*----------

     * Check to see if clause application must be delayed by outer-join

     * considerations.

     *

     * A word about is_pushed_down: we mark the qual as "pushed down" if

     * it is (potentially) applicable at a level different from its original

     * syntactic level.  This flag is used to distinguish OUTER JOIN ON quals

     * from other quals pushed down to the same joinrel.  The rules are:

     *        WHERE quals and INNER JOIN quals: is_pushed_down = true.

     *        Non-degenerate OUTER JOIN quals: is_pushed_down = false.

     *        Degenerate OUTER JOIN quals: is_pushed_down = true.

     * A "degenerate" OUTER JOIN qual is one that doesn't mention the

     * non-nullable side, and hence can be pushed down into the nullable side

     * without changing the join result.  It is correct to treat it as a

     * regular filter condition at the level where it is evaluated.

     *

     * Note: it is not immediately obvious that a simple boolean is enough

     * for this: if for some reason we were to attach a degenerate qual to

     * its original join level, it would need to be treated as an outer join

     * qual there.    However, this cannot happen, because all the rels the

     * clause mentions must be in the outer join's min_righthand, therefore

     * the join it needs must be formed before the outer join; and we always

     * attach quals to the lowest level where they can be evaluated.  But

     * if we were ever to re-introduce a mechanism for delaying evaluation

     * of "expensive" quals, this area would need work.

     *----------

     */

    if (is_deduced)

    {

        /*

         * If the qual came from implied-equality deduction, it should not be

         * outerjoin-delayed, else deducer blew it.  But we can't check this

         * because the join_info_list may now contain OJs above where the qual

         * belongs.

         */

        Assert(!ojscope);

        is_pushed_down = true;

        ...

    }

    else if (bms_overlap(relids, outerjoin_nonnullable))

    {

        /*

         * The qual is attached to an outer join and mentions (some of the)

         * rels on the nonnullable side, so it's not degenerate.

         *

         * We can't use such a clause to deduce equivalence (the left and

         * right sides might be unequal above the join because one of them has

         * gone to NULL) ... but we might be able to use it for more limited

         * deductions, if it is mergejoinable.    So consider adding it to the

         * lists of set-aside outer-join clauses.

         */

        is_pushed_down = false;

        ...

    }

    else

    {

        /*

         * Normal qual clause or degenerate outer-join clause.    Either way, we

         * can mark it as pushed-down.

         */

        is_pushed_down = true;



        ...

    }

    ...

}

此时，通过上述调用关系来调用 distribute_qual_to_rels的时候：是这样的：is_deduced参数为真

void

process_implied_equality(PlannerInfo *root,

                         Oid opno,

                         Oid collation,

                         Expr *item1,

                         Expr *item2,

                         Relids qualscope,

                         bool below_outer_join,

                         bool both_const)

{
    ...

     /*
      * Push the new clause into all the appropriate restrictinfo lists.
      */
     distribute_qual_to_rels(root, (Node *) clause,
       true, below_outer_join, JOIN_INNER,
       qualscope, NULL, NULL);
    ...
}

此时，is_pushed_down会被设置为true。

那么，何时会触发此种调用关系呢（由于下面的 and c.cust_id=2 部分的存在而导致）：

postgres=# select * from sales s ,customers c where s.cust_id = c.cust_id and c.cust_id=2;

 cust_id |  item  | cust_id | cust_name 

---------+--------+---------+-----------

       2 | camera |       2 | John Doe

(1 row)



postgres=# 

 继续追击，看看什么条件会触发 distribute_qual_to_rels 函数的 

else if (bms_overlap(relids, outerjoin_nonnullable)) 分支 和  else 分支：

调查结果：

else if (bms_overlap(relids, outerjoin_nonnullable)) 分支

postgres=# select * from sales s left outer join customers c on s.cust_id = c.cust_id;

 cust_id |   item   | cust_id | cust_name 

---------+----------+---------+-----------

       2 | camera   |       2 | John Doe

       3 | computer |       3 | Jane Doe

       3 | monitor  |       3 | Jane Doe

       4 | printer  |         | 

(4 rows)



postgres=# 

或者

postgres=# select * from sales s full outer join customers c on s.cust_id = c.cust_id;

 cust_id |   item   | cust_id | cust_name 

---------+----------+---------+-----------

         |          |       1 | craig

       2 | camera   |       2 | John Doe

       3 | computer |       3 | Jane Doe

       3 | monitor  |       3 | Jane Doe

       4 | printer  |         | 

(5 rows)



postgres=# 

else分支：

postgres=# select * from sales s inner join customers c on s.cust_id = c.cust_id;

 cust_id |   item   | cust_id | cust_name 

---------+----------+---------+-----------

       2 | camera   |       2 | John Doe

       3 | computer |       3 | Jane Doe

       3 | monitor  |       3 | Jane Doe

(3 rows)



postgres=#