PostgreSQL在何处处理 sql查询之二十七
接前面，仔细看这个 ：这 add_base_rels_to_query 是个递归调用嘛。
想像一下： select * from tst01 where id in (select sid from tst02) or id in (select sid from tst03) 之类的，此函数将层层深入，构造一个二叉树式样的语法树。
void add_base_rels_to_query(PlannerInfo *root, Node *jtnode) { if (jtnode == NULL) return; if (IsA(jtnode, RangeTblRef)) { int varno = ((RangeTblRef *) jtnode)->rtindex; (void) build_simple_rel(root, varno, RELOPT_BASEREL); } else if (IsA(jtnode, FromExpr)) { FromExpr *f = (FromExpr *) jtnode; ListCell *l; foreach(l, f->fromlist) add_base_rels_to_query(root, lfirst(l)); } else if (IsA(jtnode, JoinExpr)) { JoinExpr *j = (JoinExpr *) jtnode; add_base_rels_to_query(root, j->larg); add_base_rels_to_query(root, j->rarg); } else elog(ERROR, "unrecognized node type: %d", (int) nodeTag(jtnode)); }
这个时候，我想到一个问题，在PostgreSQL中，有没有并行查询的可能呢？
那么，再上溯到更高的层面，再次梳理一下：
exec_simple_query中调用 了 plan_tree_list，从语法分析树得到了计划树...执行 PortalRun。
而上面的 add_base_rels_to_query 是plan_tree_list 里的一部分。
调用关系如下：
plan_tree_list -->pg_plan_queries-->pg_plan_query-->planner
planner-->subquery_planner-->groupingplanner
groupingplanner-->query_planner-->add_base_rels_to_query
/* * exec_simple_query * * Execute a "simple Query" protocol message. */ static void exec_simple_query(const char *query_string) { ... isTopLevel = (list_length(parsetree_list) == 1); ... foreach(parsetree_item, parsetree_list) { ... querytree_list = pg_analyze_and_rewrite(parsetree, query_string, NULL, 0); plantree_list = pg_plan_queries(querytree_list, 0, NULL); ... /* * Create unnamed portal to run the query or queries in. If there * already is one, silently drop it. */ portal = CreatePortal("", true, true); /* Don't display the portal in pg_cursors */ portal->visible = false; /* * We don't have to copy anything into the portal, because everything * we are passing here is in MessageContext, which will outlive the * portal anyway. */ PortalDefineQuery(portal, NULL, query_string, commandTag, plantree_list, NULL); /* * Start the portal. * * If we took a snapshot for parsing/planning, the portal may be able * to reuse it for the execution phase. Currently, this will only * happen in PORTAL_ONE_SELECT mode. But even if PortalStart doesn't * end up being able to do this, keeping the parse/plan snapshot * around until after we start the portal doesn't cost much. */ PortalStart(portal, NULL, 0, snapshot_set); ... /* * Run the portal to completion, and then drop it (and the receiver). */ (void) PortalRun(portal, FETCH_ALL, isTopLevel, receiver, receiver, completionTag); (*receiver->rDestroy) (receiver); PortalDrop(portal, false); ... } /* end loop over parsetrees */ /* * Close down transaction statement, if one is open. */ finish_xact_command(); ... }
加入调试信息，看看一个带子查询的SQL，能否有并行查询的可能。
[postgres@lex pgsql]$ ./bin/psql psql (9.2.1) Type "help" for help. postgres=# select * from tst01 where id IN (select sid from tst02) or id IN (select sid from tst03); id ----- 100 200 (2 rows) postgres=#
看后台的信息，知道planner调用了三次，PortalRun只调用了一次。
[postgres@lex pgsql]$ ./bin/pg_ctl -D ./data start server starting [postgres@lex pgsql]$ LOG: database system was shut down at 2013-05-29 10:12:02 CST LOG: autovacuum launcher started LOG: database system is ready to accept connections In query_planner.... by process 11796 In get_relation_info ...oid of table is: 16387 ...by process 11796 In query_planner.... by process 11796 In query_planner.... by process 11796 In get_relation_info ...oid of table is: 16390 ...by process 11796 In query_planner.... by process 11796 In query_planner.... by process 11796 In get_relation_info ...oid of table is: 16384 ...by process 11796 In query_planner.... by process 11796 In PortalRun ... by 11796
也就是说，PostgreSQL 没有子查询的并行查询能力了？！
至少目前，它还非常地不完整：
http://postgresql.1045698.n5.nabble.com/Parallel-query-execution-td5740431.html
http://wiki.postgresql.org/wiki/Parallel_Query_Execution
各种集群方案也作不到这点：
http://www.postgresql.org/docs/current/static/different-replication-solutions.html
Many of the above solutions allow multiple servers to handle multiple queries, but none allow a single query to use multiple servers to complete faster.
对比下Oracle的：