Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the functions of fetch_upper_rel and get_cheapest_fractional_path in PostgreSQL

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the function of fetch_upper_rel and get_cheapest_fractional_path functions in PostgreSQL". In daily operation, it is believed that many people have doubts about the function of fetch_upper_rel and get_cheapest_fractional_path functions in PostgreSQL. The editor consulted all kinds of materials and sorted out simple and useful operation methods. I hope it will be helpful for you to answer the question of "what are the functions of fetch_upper_rel and get_cheapest_fractional_path in PostgreSQL?" Next, please follow the editor to study!

The fetch_upper_rel function is built to represent the final relationship generated by the query optimizer (represented by the RelOptInfo data structure), and the get_cheapest_fractional_path function finds the lowest cost access path according to the input RelOptInfo data structure.

I. Source code interpretation

Fetch_upper_rel

The final relationship generated by the query optimizer is obtained from the upper_rels data in the optimizer information.

/ /-fetch_upper_rel/* * fetch_upper_rel * Build a RelOptInfo describing some post-scan/join query processing, * or return a pre-existing one if somebody already built it. * build a RelOptInfo data structure to represent the post-scan/join query process. If it already exists, return directly. * * An "upper" relation is identified by an UpperRelationKind and a Relids set. * The meaning of the Relids set is not specified here, and very likely will * vary for different relation kinds. * A "superior" relationship is identified by a UpperRelationKind and a Relids collection. * the meaning of the Relids collection is not specified here and is likely to vary depending on the type of relationship. * * Most of the fields in an upper-level RelOptInfo are not used and are not * set here (though makeNode should ensure they're zeroes) We basically only * care about fields that are of interest to add_path () and set_cheapest (). * most of the fields in the upper RelOptInfo are not used and are not set here (although makeNode should make sure they are NULL). * basically only care about the fields of interest to the add_path () and set_cheap () functions. * / RelOptInfo * fetch_upper_rel (PlannerInfo * root, UpperRelationKind kind, Relids relids) {RelOptInfo * upperrel; ListCell * lc; / * For the moment, our indexing data structure is just a List for each * relation kind. If we ever get so many of one kind that this stops * working well, we can improve it. No code outside this function should * assume anything about how to find a particular upperrel. * currently, the data structure we have indexed is just a linked list for each relationship type. * No code other than this function should assume how to find a particular upper-level relationship. * / * If we already made this upperrel for the query, return it * / if the upper layer relationship of the query has been constructed, return foreach (lc, root- > upper_ [kind]) {upperrel = (RelOptInfo *) lfirst (lc); if (bms_equal (upperrel- > relids, relids) return upperrel;} upperrel = makeNode (RelOptInfo); upperrel- > reloptkind = RELOPT_UPPER_REL Upperrel- > relids = bms_copy (relids); / * cheap startup cost is interesting iff not all tuples to be retrieved * / / the low startup cost is of concern when fewer tuples are returned. Upperrel- > consider_startup = (root- > tuple_fraction > 0); / / if not all tuples are returned, the startup cost upperrel- > consider_param_startup = false; upperrel- > consider_parallel = false; / * may change later; might get changed later * / upperrel- > reltarget = create_empty_pathtarget (); upperrel- > pathlist = NIL; upperrel- > cheapest_startup_path = NULL; upperrel- > cheapest_total_path = NULL Upperrel- > cheapest_unique_path = NULL; upperrel- > cheapest_parameterized_paths = NIL; root- > upper_ rels[ kind] = lappend (root- > upper_rels [kind], upperrel); return upperrel;}

Get_cheapest_fractional_path

Get_cheapest_fractional_path obtains the lowest cost access path by pairwise comparison of access paths in RelOptInfo.

/ /-get_cheapest_fractional_path/* * get_cheapest_fractional_path * Find the cheapest path for retrieving a specified fraction of all * the tuples expected to be returned by the given relation * given the relationship, find the access path with the lowest cost, which returns the expected number of tuples. * * We interpret tuple_fraction the same way as grouping_planner. * We use the grouping_planner function to get tuple_fraction. * * We assume set_cheapest () has been run on the given rel. * assume that the set_cheapest () function has been executed on a given relationship. * / Path * get_cheapest_fractional_path (RelOptInfo * rel, double tuple_fraction) {Path * best_path = rel- > cheapest_total_path; ListCell * l; / * If all tuples will be retrieved, just return the cheapest-total path * / / if you need to retrieve all tuples, return the access path with the lowest total cost if (tuple_fraction = 1.0 & & best_path- > rows > 0) tuple_fraction / = best_path- > rows Foreach (l, rel- > pathlist) {Path * path = (Path *) lfirst (l); / / the cost of best_path is lower or the same as that of path, keep if (path = = rel- > cheapest_total_path | | compare_fractional_path_costs (best_path, path, tuple_fraction) startup_cost + fraction * (path2- > total_cost-path2- > startup_cost) Cost2 = path3- > startup_cost + fraction * (path3- > total_cost-path3- > startup_cost); if (cost1)

< cost2) return -1; if (cost1 >

Cost2) return + 1; return 0;} / /-- compare_path_costs / * * compare_path_costs * Return-1, 0, or + 1 according as path2 is cheaper, the same cost, * or more expensive than path3 for the specified criterion. * A comparison result is returned when the standard is given. * return value: *-1: lower cost relative to path3,path2; * 0: same as path3 cost * 1: higher than path3 cost * / int compare_path_costs (Path * path2, Path * path3, CostSelector criterion) {if (criterion = = STARTUP_COST) / / startup cost {if (path2- > startup_cost)

< path3->

Startup_cost) return-1; if (path2- > startup_cost > path3- > startup_cost) return + 1; / * If paths have the same startup cost (not at all unlikely), order * them by total cost. * / if (path2- > total_cost)

< path3->

Total_cost) return-1; if (path2- > total_cost > path3- > total_cost) return + 1;} else// Total cost {if (path2- > total_cost)

< path3->

Total_cost) return-1; if (path2- > total_cost > path3- > total_cost) return + 1; / * If paths have the same total cost, order them by startup cost. * / if (path2- > startup_cost)

< path3->

Startup_cost) return-1; if (path2- > startup_cost > path3- > startup_cost) return + 1;} return 0;} at this point, the study of "what are the functions of fetch_upper_rel and get_cheapest_fractional_path functions in PostgreSQL" is over, hoping to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 230

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report