PostgreSQL在何处处理 sql查询之六十一

对Join的成本计算的调用路径:

make_one_rel

  ->make_rel_from_joinlist

       ->standard_join_search

             -> join_search_one_level

                   -> make_join_rel

                         -> add_paths_to_joinrel

                               ->hash_inner_and_outer

                                     ->try_hashjoin_path

                                         ->initial_cost_hashjoin

 在make_join_rel函数中,有如下的代码:

PostgreSQL在何处处理 sql查询之六十一
RelOptInfo *
make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
{
    ...

        /*
     * Consider paths using each rel as both outer and inner.  Depending on
     * the join type, a provably empty outer or inner rel might mean the join
     * is provably empty too; in which case throw away any previously computed
     * paths and mark the join as dummy.  (We do it this way since it's
     * conceivable that dummy-ness of a multi-element join might only be
     * noticeable for certain construction paths.)
     *
     * Also, a provably constant-false join restriction typically means that
     * we can skip evaluating one or both sides of the join.  We do this by
     * marking the appropriate rel as dummy.  For outer joins, a
     * constant-false restriction that is pushed down still means the whole
     * join is dummy, while a non-pushed-down one means that no inner rows
     * will join so we can treat the inner rel as dummy.
     *
     * We need only consider the jointypes that appear in join_info_list, plus
     * JOIN_INNER.
     */
    switch (sjinfo->jointype)
    {
        case JOIN_INNER:

            fprintf(stderr,"JOIN_INNER \n");

            if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
                restriction_is_constant_false(restrictlist, false))
            {
                mark_dummy_rel(joinrel);
                break;
            }
            add_paths_to_joinrel(root, joinrel, rel1, rel2,
                                 JOIN_INNER, sjinfo,
                                 restrictlist);
            add_paths_to_joinrel(root, joinrel, rel2, rel1,
                                 JOIN_INNER, sjinfo,
                                 restrictlist);
            break;
        case  JOIN_LEFT:
            ...
            break;
        case  JOIN_FULL:
            ...
            break;
        case  JOIN_SEMI:
            ...
            break;
        case  JOIN_ANTI:
            ...
            break;
         ...
     }
     ...
}
PostgreSQL在何处处理 sql查询之六十一






上一篇:区块链赋能跨境贸易的“最后一公里” ——“跨境贸易风险监测与可信溯源平台” 成功上线


下一篇:PostgreSQL在何处处理 sql查询之五十九