ReDistribution plan细节

In a Greenplum cluster with 4 segments, when you perform a join between two tables (sales and customer) that are distributed differently, the query plan will involve redistributing data to ensure that related rows are on the same segment. Here's a detailed breakdown of how the redistribution query plan might look:

Tables and Distribution Keys

  • sales table : Distributed by sale_id.

  • customer table : Distributed by cust_id.

Query

sql 复制代码
SELECT s.sale_id, s.amount, c.cust_name
FROM sales s
JOIN customer c ON s.cust_id = c.cust_id;

Query Plan Breakdown

  1. Initial Scan:

    • Each segment scans its local portion of the sales and customer tables.

    • Segment 1 : Scans sales and customer data assigned to it.

    • Segment 2 : Scans sales and customer data assigned to it.

    • Segment 3 : Scans sales and customer data assigned to it.

    • Segment 4 : Scans sales and customer data assigned to it.

  2. Redistribute Motion:

    • Since the sales table is distributed by sale_id and the customer table is distributed by cust_id, the join condition s.cust_id = c.cust_id requires that tuples from sales be redistributed by cust_id.

    • The query plan will include a redistribute motion operator to redistribute the sales table based on cust_id.

  3. Redistribution Execution:

    • The redistribute motion operator will redistribute the sales table across all segments based on the cust_id column.

    • Each segment will receive a portion of the sales table that matches its portion of the customer table.

  4. Local Join:

    • After redistribution, each segment will perform a local join between the redistributed sales data and its local customer data.

    • Segment 1 : Joins redistributed sales data with local customer data.

    • Segment 2 : Joins redistributed sales data with local customer data.

    • Segment 3 : Joins redistributed sales data with local customer data.

    • Segment 4 : Joins redistributed sales data with local customer data.

  5. Gather Motion:

    • The results from each segment are gathered back to the master node.

    • The master node combines the results from all segments to produce the final query result.

Example Query Plan

Here's a simplified example of what the query plan might look like:

复制代码
Gather Motion 4:1  (slice1; segments: 4)
  ->  Hash Join
        Hash Cond: (s.cust_id = c.cust_id)
        ->  Redistribute Motion 4:4  (slice2; segments: 4)
            Hash Key: s.cust_id
            ->  Seq Scan on sales s
        ->  Seq Scan on customer c

Explanation

  1. Gather Motion 4:1:

    • Collects the final results from all 4 segments and combines them on the master node.
  2. Hash Join:

    • Performs a hash join on the cust_id column between the sales and customer tables.
  3. Redistribute Motion 4:4:

    • Redistributes the sales table across all 4 segments based on the cust_id column.
  4. Seq Scan on sales s:

    • Each segment performs a sequential scan on its local portion of the sales table.
  5. Seq Scan on customer c:

    • Each segment performs a sequential scan on its local portion of the customer table.

Conclusion

In this query plan, the redistribution of the sales table based on cust_id ensures that related rows are on the same segment, allowing for efficient local joins. The results from each segment are then gathered back to the master node to produce the final result. This approach leverages Greenplum's MPP architecture to achieve parallel processing and efficient query execution.

相关推荐
朱小弟cs68 分钟前
Orange的运维学习日记--16.Linux时间管理
linux·运维·学习
chen_note17 分钟前
LAMP及其环境的部署搭建
linux·运维·mysql·php·apache·lamp·phpmyadmin
夕泠爱吃糖23 分钟前
Linux 操作系统
linux·运维·服务器
曾几何时`25 分钟前
MySQL(配置)——MariaDB使用
数据库·mysql
努力学习java的哈吉米大王29 分钟前
MySQL——MVCC
数据库·mysql
数据要素X42 分钟前
【数据架构10】数字政府架构篇
大数据·运维·数据库·人工智能·架构
专注VB编程开发20年1 小时前
winsock socket通讯为什么UDP服务器无法获取客户端IP?
服务器·tcp/ip·udp
G_H_S_3_1 小时前
【网络运维】 Linux:使用 Cockpit 管理服务器
运维·服务器·网络
lixzest1 小时前
Redis实现数据传输简介
数据库·redis·缓存
搬砖的小熊猫1 小时前
MySQL常见面试题
数据库·mysql