怎么用asp.net做网站,siren wordpress,查国外网站备案,网站制作公司的网站摘要:
2024-05-08 postgres-火山模型-执行-记录
上下文: 2024-05-08 postgres-调试及分析-记录-CSDN博客 火山模型: 数据流是在查询树上#xff0c;自上而下进行拉取#xff0c;由上而下的调用。树本身就表明了数据的流动。每次执行一个元组#xff0c;也就类似于迭代器的…
摘要:
2024-05-08 postgres-火山模型-执行-记录
上下文: 2024-05-08 postgres-调试及分析-记录-CSDN博客 火山模型: 数据流是在查询树上自上而下进行拉取由上而下的调用。树本身就表明了数据的流动。每次执行一个元组也就类似于迭代器的模式。执行到最底层是scan table算子一次获取一行数据。上层的算子不断地GetNext的调用下层算子在本算子进行运算。 查询执行计划: d1# EXPLAIN ANALYZE VERBOSE
d1-# SELECT * FROM t1 LEFT JOIN t2 ON t2.a t1.a WHERE t2.b 5;
***(Single step mode: verify command)*******************************************
EXPLAIN ANALYZE VERBOSE
SELECT * FROM t1 LEFT JOIN t2 ON t2.a t1.a WHERE t2.b 5;
***(press return to proceed or enter x and return to cancel)********************QUERY PLAN
-------------------------------------------------------------------------------------------------------------------Merge Join (cost232.74..364.14 rows8509 width16) (actual time0.032..0.035 rows1 loops1)Output: t1.a, t1.b, t2.a, t2.bMerge Cond: (t2.a t1.a)- Sort (cost74.23..76.11 rows753 width8) (actual time0.020..0.020 rows2 loops1)Output: t2.a, t2.bSort Key: t2.aSort Method: quicksort Memory: 25kB- Seq Scan on public.t2 (cost0.00..38.25 rows753 width8) (actual time0.010..0.012 rows2 loops1)Output: t2.a, t2.bFilter: (t2.b 5)- Sort (cost158.51..164.16 rows2260 width8) (actual time0.008..0.008 rows2 loops1)Output: t1.a, t1.bSort Key: t1.aSort Method: quicksort Memory: 25kB- Seq Scan on public.t1 (cost0.00..32.60 rows2260 width8) (actual time0.002..0.003 rows2 loops1)Output: t1.a, t1.bPlanning Time: 0.407 msExecution Time: 0.080 ms
(18 rows)函数调用堆栈: #0 heapgettup_pagemode (scan0x1443958, dirForwardScanDirection, nkeys0, key0x0) at heapam.c:917
#1 0x00000000004db32a in heap_getnextslot (sscan0x1443958, directionForwardScanDirection, slot0x1432a78) at heapam.c:1398
#2 0x0000000000730ec5 in table_scan_getnextslot (sscan0x1443958, directionForwardScanDirection, slot0x1432a78) at ../../../src/include/access/tableam.h:1044
#3 0x0000000000730f97 in SeqNext (node0x14328d8) at nodeSeqscan.c:80
#4 0x00000000006f860d in ExecScanFetch (node0x14328d8, accessMtd0x730efe SeqNext, recheckMtd0x730fa8 SeqRecheck) at execScan.c:133
#5 0x00000000006f86b3 in ExecScan (node0x14328d8, accessMtd0x730efe SeqNext, recheckMtd0x730fa8 SeqRecheck) at execScan.c:199
#6 0x0000000000730ff3 in ExecSeqScan (pstate0x14328d8) at nodeSeqscan.c:112
#7 0x0000000000732343 in ExecProcNode (node0x14328d8) at ../../../src/include/executor/executor.h:257
#8 0x000000000073248a in ExecSort (pstate0x14326c8) at nodeSort.c:108
#9 0x00000000006f4ca9 in ExecProcNodeFirst (node0x14326c8) at execProcnode.c:463
#10 0x0000000000726e97 in ExecProcNode (node0x14326c8) at ../../../src/include/executor/executor.h:257
#11 0x0000000000727af0 in ExecMergeJoin (pstate0x14322b8) at nodeMergejoin.c:656
#12 0x00000000006f4ca9 in ExecProcNodeFirst (node0x14322b8) at execProcnode.c:463
#13 0x00000000006ea204 in ExecProcNode (node0x14322b8) at ../../../src/include/executor/executor.h:257
#14 0x00000000006ec6bb in ExecutePlan (estate0x1432078, planstate0x14322b8, use_parallel_modefalse, operationCMD_SELECT, sendTuplestrue, numberTuples0, directionForwardScanDirection, dest0x1423f98, execute_oncetrue) at execMain.c:1551
#15 0x00000000006ea76a in standard_ExecutorRun (queryDesc0x136dfc8, directionForwardScanDirection, count0, execute_oncetrue) at execMain.c:361
#16 0x00000000006ea602 in ExecutorRun (queryDesc0x136dfc8, directionForwardScanDirection, count0, execute_oncetrue) at execMain.c:305
#17 0x000000000090c03e in PortalRunSelect (portal0x13ad5d8, forwardtrue, count0, dest0x1423f98) at pquery.c:921
#18 0x000000000090bd2d in PortalRun (portal0x13ad5d8, count9223372036854775807, isTopLeveltrue, run_oncetrue, dest0x1423f98, altdest0x1423f98, qc0x7ffff3ea58b0)at pquery.c:765
#19 0x0000000000905d39 in exec_simple_query (query_string0x134a598 SELECT * FROM t1 LEFT JOIN t2 ON t2.a t1.a WHERE t2.b 5;) at postgres.c:1214
#20 0x000000000090a0ef in PostgresMain (argc1, argv0x7ffff3ea5b40, dbname0x13775d8 d1, username0x1345a48 kevin) at postgres.c:4496
#21 0x0000000000857a54 in BackendRun (port0x136f010) at postmaster.c:4530
#22 0x00000000008573c1 in BackendStartup (port0x136f010) at postmaster.c:4252
#23 0x0000000000853b10 in ServerLoop () at postmaster.c:1745
#24 0x00000000008533c9 in PostmasterMain (argc1, argv0x1343a00) at postmaster.c:1417
#25 0x0000000000760270 in main (argc1, argv0x1343a00) at main.c:209分析 从查询执行的函数调用堆栈可以看到很明确的在查询树中由上层算子调用下层算子数据的流动在查询树中由上而下的进行拉取最底层执行的算子是ExecScanFetch一次获取一行的数据pg的查询执行的抽象程度很好每个算子抽象成node 整体大的框架确定后每个算子单独进行物理执行的实现 参考 PostgreSQL 基于heap表 存储引擎实现原理 - 知乎 (zhihu.com)
