PostgreSQL在何处处理 sql查询之五十二

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介:

开始

    /*
     * Ready to do the primary planning.
     */
    final_rel = make_one_rel(root, joinlist); 

展开:

复制代码
/*
 * make_one_rel
 *      Finds all possible access paths for executing a query, returning a
 *      single rel that represents the join of all base rels in the query.
 */
RelOptInfo *
make_one_rel(PlannerInfo *root, List *joinlist)
{
    RelOptInfo *rel;
    Index        rti;

    /*
     * Construct the all_baserels Relids set.
     */
    root->all_baserels = NULL;
    for (rti = 1; rti < root->simple_rel_array_size; rti++)
    {
        RelOptInfo *brel = root->simple_rel_array[rti];

        /* there may be empty slots corresponding to non-baserel RTEs */
        if (brel == NULL)
            continue;

        Assert(brel->relid == rti);        /* sanity check on array */

        /* ignore RTEs that are "other rels" */
        if (brel->reloptkind != RELOPT_BASEREL)
            continue;

        root->all_baserels = bms_add_member(root->all_baserels, brel->relid);
    }

    /*
     * Generate access paths for the base rels.
     */
    set_base_rel_sizes(root);
    set_base_rel_pathlists(root);

    /*
     * Generate access paths for the entire join tree.
     */
    rel = make_rel_from_joinlist(root, joinlist);

    /*
     * The result should join all and only the query's base rels.
     */
    Assert(bms_equal(rel->relids, root->all_baserels));

    return rel;
}
复制代码

其中, 

root->all_baserels = bms_add_member(root->all_baserels, brel->relid);

这个展开后可以看到,因为 root->all_baserels 是NULL,所以什么也没执行。

复制代码
/*
 * bms_add_member - add a specified member to set
 *
 * Input set is modified or recycled!
 */
Bitmapset *
bms_add_member(Bitmapset *a, int x)
{
    int            wordnum,
                bitnum;

    if (x < 0)
        elog(ERROR, "negative bitmapset member not allowed");

    if (a == NULL)
        return bms_make_singleton(x);

    wordnum = WORDNUM(x);
    bitnum = BITNUM(x);if (wordnum >= a->nwords)
    {
        /* Slow path: make a larger set and union the input set into it */
        Bitmapset  *result;
        int            nwords;
        int            i;

        result = bms_make_singleton(x);
        nwords = a->nwords;
        for (i = 0; i < nwords; i++)
            result->words[i] |= a->words[i];
        pfree(a);
        return result;
    }
    /* Fast path: x fits in existing set */
    a->words[wordnum] |= ((bitmapword) 1 << bitnum);
    return a;
}
复制代码

接着分析下一个:

set_base_rel_sizes(root);
复制代码
/*
 * set_base_rel_sizes
 *      Set the size estimates (rows and widths) for each base-relation entry.
 *
 * We do this in a separate pass over the base rels so that rowcount
 * estimates are available for parameterized path generation.
 */
static void
set_base_rel_sizes(PlannerInfo *root)
{
    Index        rti;

    for (rti = 1; rti < root->simple_rel_array_size; rti++)
    {
        RelOptInfo *rel = root->simple_rel_array[rti];

        /* there may be empty slots corresponding to non-baserel RTEs */
        if (rel == NULL)
            continue;

        Assert(rel->relid == rti);        /* sanity check on array */

        /* ignore RTEs that are "other rels" */
        if (rel->reloptkind != RELOPT_BASEREL)
            continue;

        set_rel_size(root, rel, rti, root->simple_rte_array[rti]);
    }
}
复制代码

这是成本评估的非常重要的依据。

再展开  set_rel_size 函数:

复制代码
/*
 * set_rel_size
 *      Set size estimates for a base relation
 */
static void
set_rel_size(PlannerInfo *root, RelOptInfo *rel,
             Index rti, RangeTblEntry *rte)
{
    if (rel->reloptkind == RELOPT_BASEREL &&
        relation_excluded_by_constraints(root, rel, rte))
    {
        /*
         * We proved we don't need to scan the rel via constraint exclusion,
         * so set up a single dummy path for it.  Here we only check this for
         * regular baserels; if it's an otherrel, CE was already checked in
         * set_append_rel_pathlist().
         *
         * In this case, we go ahead and set up the relation's path right away
         * instead of leaving it for set_rel_pathlist to do.  This is because
         * we don't have a convention for marking a rel as dummy except by
         * assigning a dummy path to it.
         */
        set_dummy_rel_pathlist(rel);
    }
    else if (rte->inh)
    {
        /* It's an "append relation", process accordingly */
        set_append_rel_size(root, rel, rti, rte);
    }
    else
    {
        switch (rel->rtekind)
        {
            case RTE_RELATION:
                if (rte->relkind == RELKIND_FOREIGN_TABLE)
                {
                    /* Foreign table */
                    set_foreign_size(root, rel, rte);
                }
                else
                {
                    /* Plain relation */
                    set_plain_rel_size(root, rel, rte);
                }
                break;
            case RTE_SUBQUERY:

                /*
                 * Subqueries don't support parameterized paths, so just go
                 * ahead and build their paths immediately.
                 */
                set_subquery_pathlist(root, rel, rti, rte);
                break;
            case RTE_FUNCTION:
                set_function_size_estimates(root, rel);
                break;
            case RTE_VALUES:
                set_values_size_estimates(root, rel);
                break;
            case RTE_CTE:

                /*
                 * CTEs don't support parameterized paths, so just go ahead
                 * and build their paths immediately.
                 */
                if (rte->self_reference)
                    set_worktable_pathlist(root, rel, rte);
                else
                    set_cte_pathlist(root, rel, rte);
                break;
            default:
                elog(ERROR, "unexpected rtekind: %d", (int) rel->rtekind);
                break;
        }
    }
}
复制代码

因为我的是简单查询,所以会走到:

                    /* Plain relation */
                    set_plain_rel_size(root, rel, rte);

展开  set_plain_rel_size :

复制代码
/*
 * set_plain_rel_size
 *      Set size estimates for a plain relation (no subquery, no inheritance)
 */
static void
set_plain_rel_size(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *rte)
{
    /*
     * Test any partial indexes of rel for applicability.  We must do this
     * first since partial unique indexes can affect size estimates.
     */
    check_partial_indexes(root, rel);

    /* Mark rel with estimated output rows, width, etc */
    set_baserel_size_estimates(root, rel);

    /*
     * Check to see if we can extract any restriction conditions from join
     * quals that are OR-of-AND structures.  If so, add them to the rel's
     * restriction list, and redo the above steps.
     */
    if (create_or_index_quals(root, rel))
    {
        check_partial_indexes(root, rel);
        set_baserel_size_estimates(root, rel);
    }
}
复制代码

再对 set_baserel_size_estimates 展开一层:

复制代码
/*
 * set_baserel_size_estimates
 *        Set the size estimates for the given base relation.
 *
 * The rel's targetlist and restrictinfo list must have been constructed
 * already, and rel->tuples must be set.
 *
 * We set the following fields of the rel node:
 *    rows: the estimated number of output tuples (after applying
 *          restriction clauses).
 *    width: the estimated average output tuple width in bytes.
 *    baserestrictcost: estimated cost of evaluating baserestrictinfo clauses.
 */
void
set_baserel_size_estimates(PlannerInfo *root, RelOptInfo *rel)
{
    double        nrows;

    /* Should only be applied to base relations */
    Assert(rel->relid > 0);

    nrows = rel->tuples *
        clauselist_selectivity(root,
                               rel->baserestrictinfo,
                               0,
                               JOIN_INNER,
                               NULL);

    rel->rows = clamp_row_est(nrows);

    cost_qual_eval(&rel->baserestrictcost, rel->baserestrictinfo, root);

    set_rel_width(root, rel);
}
复制代码

rel->tuples 值是如何算得?1条记录第表,tuples 是2400, 4条的却是 2140。

得仔细研究。







本文转自健哥的数据花园博客园博客,原文链接:http://www.cnblogs.com/gaojian/archive/2013/06/06/3119002.html,如需转载请自行联系原作者

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
1月前
|
SQL 监控 关系型数据库
一键开启百倍加速!RDS DuckDB 黑科技让SQL查询速度最高提升200倍
RDS MySQL DuckDB分析实例结合事务处理与实时分析能力,显著提升SQL查询性能,最高可达200倍,兼容MySQL语法,无需额外学习成本。
|
1月前
|
SQL 存储 关系型数据库
MySQL体系结构详解:一条SQL查询的旅程
本文深入解析MySQL内部架构,从SQL查询的执行流程到性能优化技巧,涵盖连接建立、查询处理、执行阶段及存储引擎工作机制,帮助开发者理解MySQL运行原理并提升数据库性能。
|
13天前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
|
14天前
|
关系型数据库 分布式数据库 数据库
阿里云数据库收费价格:MySQL、PostgreSQL、SQL Server和MariaDB引擎费用整理
阿里云数据库提供多种类型,包括关系型与NoSQL,主流如PolarDB、RDS MySQL/PostgreSQL、Redis等。价格低至21元/月起,支持按需付费与优惠套餐,适用于各类应用场景。
|
1月前
|
SQL 监控 关系型数据库
SQL优化技巧:让MySQL查询快人一步
本文深入解析了MySQL查询优化的核心技巧,涵盖索引设计、查询重写、分页优化、批量操作、数据类型优化及性能监控等方面,帮助开发者显著提升数据库性能,解决慢查询问题,适用于高并发与大数据场景。
|
2月前
|
SQL XML Java
通过MyBatis的XML配置实现灵活的动态SQL查询
总结而言,通过MyBatis的XML配置实现灵活的动态SQL查询,可以让开发者以声明式的方式构建SQL语句,既保证了SQL操作的灵活性,又简化了代码的复杂度。这种方式可以显著提高数据库操作的效率和代码的可维护性。
167 18
|
19天前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎,提供高性价比、稳定安全的云数据库服务,适用于多种行业与业务场景。
|
2月前
|
SQL 人工智能 数据库
【三桥君】如何正确使用SQL查询语句:避免常见错误?
三桥君解析了SQL查询中的常见错误和正确用法。AI产品专家三桥君通过三个典型案例:1)属性重复比较错误,应使用IN而非AND;2)WHERE子句中非法使用聚合函数的错误,应改用HAVING;3)正确的分组查询示例。三桥君还介绍了学生、课程和选课三个关系模式,并分析了SQL查询中的属性比较、聚合函数使用和分组查询等关键概念。最后通过实战练习帮助读者巩固知识,强调掌握这些技巧对提升数据库查询效率的重要性。
97 0
|
3月前
|
SQL
SQL中如何删除指定查询出来的数据
SQL中如何删除指定查询出来的数据
|
4月前
|
SQL 存储 弹性计算
OSS Select 加速查询:10GB CSV 文件秒级过滤的 SQL 语法优化技巧
OSS Select 可直接在对象存储上执行 SQL 过滤,跳过文件下载,仅返回所需数据,性能比传统 ECS 方案提升 10~100 倍。通过减少返回列、使用等值查询、避免复杂函数、分区剪枝及压缩优化等技巧,可大幅降低扫描与传输量,显著提升查询效率并降低成本。

热门文章

最新文章

推荐镜像

更多