QE 为每个 slice 开启独立进程，在该进程内执行多个操作。每一步代表着特定的 DB 操作，比如：扫表、关联、聚合、排序等。Segment 上单个 slice 对应进程的执行算子从上向下调用，数据从下向上传递。
与典型的 DB 操作不同的是，GPDB 有一个特有的算子：移动（ motion ）。移动操作涉及到查询处理期间在 Segment 之间移动数据。motion 分为广播（ broadcast ）和重分布（ redistribute motion ）两种。正是 motion 算子将查询计划分割为一个个 slice ，上一层 slice 对应的进程会读取下一层各个 slice 进程广播或重分布的数据，然后进行计算。
Greenplum 同 PostgreSQL 一样，采用元组流水方式获取和处理数据。我们按需取出单条元组，在处理本条元组后，系统将会取出下一条满足条件的元组，直到取出所有满足条件的元组为止。slice 间的 motion 操作同样以元组为单位收发数据，并通过下层 slice 缓冲构成生产消费模型，但不会阻断整个查询的流水。最终，各 Segment 的查询结果同样通过 motion 传给 Master，Master 完成最终处理后返回查询结果。
3.容错机制 节点镜像与故障容错GPDB 支持为 Segment 配置镜像节点，单个Primary Segment 与对应的 Mirror Segment 配置在不同的物理主机上。同一物理主机可同时混合装载多个对应不同实例的 Primary Segment 和 Mirror Segment 。Primary Segment 与对应 Mirror Segment 之间的数据基于文件级别同步备份。Mirror Segment 不直接参与数据库事务和控制操作。
当 Primary Segment 不可访问时，系统会自动切换到其对应的 Mirror Segment 上，此时，Mirror Segment 取代 Primary Segment 的作用。只要剩余的可用 Segment 能够保证数据完整性，在个别 Segment 或者物理主机宕机时，GPDB系统仍可能通过 Primary/Mirror 身份切换，来保持系统整体的可用状态。
其具体切换过程是，每当 Master 发现无法连接到某 Primary Segment 时（ FTS系统），会在 GPDB 的系统日志表中标记失败状态，并激活/唤醒对应的 Mirror Segment 取代原有的 Primary Segment 继续完成后续工作。失败的 Primary Segment 可以等恢复工作能力后，在系统处于运行状态时切换回来。