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

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

接前面。

从 cheapest_total_path 来看:

query_planner 会先调用  build_simple_rel,这里完成了  cheapest_total_path 的初始化。

(query_planner --> add_base_rels_to_query --> query_planner)

然后,query_planner 再在后面调用 create_plan,最终设置 plan_rows。

那么,是在何处 设置了 cheapest_total_path 的值呢?

经过查找,看到了如下的调用关系:

make_one_rel--> set_base_rel_pathlists --> set_rel_pathlist --> set_plain_rel_pathlist--> set_cheapest

先看 set_cheapest:

复制代码
/*
 * set_cheapest
 *      Find the minimum-cost paths from among a relation's paths,
 *      and save them in the rel's cheapest-path fields.
 *
 * Only unparameterized paths are considered candidates for cheapest_startup
 * and cheapest_total.    The cheapest_parameterized_paths list collects paths
 * that are cheapest-total for their parameterization (i.e., there is no
 * cheaper path with the same or weaker parameterization).    This list always
 * includes the unparameterized cheapest-total path, too.
 *
 * This is normally called only after we've finished constructing the path
 * list for the rel node.
 */
void
set_cheapest(RelOptInfo *parent_rel)
{
    fprintf(stderr,"In set_cheapest ........\n");

    Path       *cheapest_startup_path;
    Path       *cheapest_total_path;
    bool        have_parameterized_paths;
    ListCell   *p;

    Assert(IsA(parent_rel, RelOptInfo));

    cheapest_startup_path = cheapest_total_path = NULL;
    have_parameterized_paths = false;

    foreach(p, parent_rel->pathlist)
    {
        Path       *path = (Path *) lfirst(p);
        int            cmp;

        /* We only consider unparameterized paths in this step */
        if (path->param_info)
        {
            have_parameterized_paths = true;
            continue;
        }

        if (cheapest_total_path == NULL)
        {
            cheapest_startup_path = cheapest_total_path = path;
            continue;
        }

        /*
         * If we find two paths of identical costs, try to keep the
         * better-sorted one.  The paths might have unrelated sort orderings,
         * in which case we can only guess which might be better to keep, but
         * if one is superior then we definitely should keep that one.
         */
        cmp = compare_path_costs(cheapest_startup_path, path, STARTUP_COST);
        if (cmp > 0 ||
            (cmp == 0 &&
             compare_pathkeys(cheapest_startup_path->pathkeys,
                              path->pathkeys) == PATHKEYS_BETTER2))
            cheapest_startup_path = path;

        cmp = compare_path_costs(cheapest_total_path, path, TOTAL_COST);
        if (cmp > 0 ||
            (cmp == 0 &&
             compare_pathkeys(cheapest_total_path->pathkeys,
                              path->pathkeys) == PATHKEYS_BETTER2))
            cheapest_total_path = path;
    }

    if (cheapest_total_path == NULL)
        elog(ERROR, "could not devise a query plan for the given query");

    parent_rel->cheapest_startup_path = cheapest_startup_path;
    parent_rel->cheapest_total_path = cheapest_total_path;
    parent_rel->cheapest_unique_path = NULL;    /* computed only if needed */

    /* Seed the parameterized-paths list with the cheapest total */
    parent_rel->cheapest_parameterized_paths = list_make1(cheapest_total_path);

    /* And, if there are any parameterized paths, add them in one at a time */
    if (have_parameterized_paths)
    {
        foreach(p, parent_rel->pathlist)
        {
            Path       *path = (Path *) lfirst(p);

            if (path->param_info)
                add_parameterized_path(parent_rel, path);
        }
    }
}
复制代码
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
1天前
|
SQL NoSQL Java
Java使用sql查询mongodb
通过使用 MongoDB Connector for BI 和 JDBC,开发者可以在 Java 中使用 SQL 语法查询 MongoDB 数据库。这种方法对于熟悉 SQL 的团队非常有帮助,能够快速实现对 MongoDB 数据的操作。同时,也需要注意到这种方法的性能和功能限制,根据具体应用场景进行选择和优化。
23 9
|
22天前
|
SQL 存储 人工智能
Vanna:开源 AI 检索生成框架,自动生成精确的 SQL 查询
Vanna 是一个开源的 Python RAG(Retrieval-Augmented Generation)框架,能够基于大型语言模型(LLMs)为数据库生成精确的 SQL 查询。Vanna 支持多种 LLMs、向量数据库和 SQL 数据库,提供高准确性查询,同时确保数据库内容安全私密,不外泄。
92 7
Vanna:开源 AI 检索生成框架,自动生成精确的 SQL 查询
|
29天前
|
SQL Java
使用java在未知表字段情况下通过sql查询信息
使用java在未知表字段情况下通过sql查询信息
36 8
|
1月前
|
SQL 安全 PHP
PHP开发中防止SQL注入的方法,包括使用参数化查询、对用户输入进行过滤和验证、使用安全的框架和库等,旨在帮助开发者有效应对SQL注入这一常见安全威胁,保障应用安全
本文深入探讨了PHP开发中防止SQL注入的方法,包括使用参数化查询、对用户输入进行过滤和验证、使用安全的框架和库等,旨在帮助开发者有效应对SQL注入这一常见安全威胁,保障应用安全。
59 4
|
1月前
|
SQL 监控 关系型数据库
SQL语句当前及历史信息查询-performance schema的使用
本文介绍了如何使用MySQL的Performance Schema来获取SQL语句的当前和历史执行信息。Performance Schema默认在MySQL 8.0中启用,可以通过查询相关表来获取详细的SQL执行信息,包括当前执行的SQL、历史执行记录和统计汇总信息,从而快速定位和解决性能瓶颈。
|
1月前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
151 10
|
1月前
|
SQL 关系型数据库 MySQL
|
1月前
|
SQL 关系型数据库 数据库
PostgreSQL性能飙升的秘密:这几个调优技巧让你的数据库查询速度翻倍!
【10月更文挑战第25天】本文介绍了几种有效提升 PostgreSQL 数据库查询效率的方法,包括索引优化、查询优化、配置优化和硬件优化。通过合理设计索引、编写高效 SQL 查询、调整配置参数和选择合适硬件,可以显著提高数据库性能。
366 1
|
2月前
|
SQL 数据库 开发者
功能发布-自定义SQL查询
本期主要为大家介绍ClkLog九月上线的新功能-自定义SQL查询。
|
1月前
|
SQL 关系型数据库 MySQL
mysql编写sql脚本:要求表没有主键,但是想查询没有相同值的时候才进行插入
mysql编写sql脚本:要求表没有主键,但是想查询没有相同值的时候才进行插入
35 0