并发管理涉及两方面的问题
一方面是保证并发事务一致性，另一方面是有效管理资源队列。
Greenplum并发和事务管理基于PostgreSQL单节点的MVCC（Multi-Version Concurrency Control，多版本并发控制）和快照特性，并开发了自有的、完备的分布式事务管理机制。PostgreSQL对每个事务都会分配相应的事务ID，对操作的数据行会附加隐藏的执行事务ID。
例如，修改一行时，就会创建一个该行的新版本，当一个新的事务或者语句执行时会获取一个系统快照，快照中包含系统中事务的状态和开始时间。接下来的操作就会根据这些信息获取、操作数据行，从而高效地完成并发的增删改查。
Greenplum在上述基础上又引入了全局分布式事务，通过在Master节点获取全局快照来协调同步每个Segment节点的工作，通过两阶段提交来确保事务在所有节点上的一致状态。
资源队列的作用在现实生活中也随处可见。在银行或者酒店有限的柜台前，如果大家都挤上去，可能每个客户都得不到满意的服务，但如果有一个秩序良好的队列，大家逐个来到柜台前办理业务，那么用户体验会更好。同理，面对有限的数据库资源，如果瞬时用户提交的语句太多，系统资源会分得太细，每个用户的操作会变得非常缓慢，那么通过资源队列可以很好地解决这样的问题。当创建资源组时，通过指定并发数量，就限定了在同一时刻该资源组允许并发执行的最大语句数，其他请求则需要排队等待运行中的任一语句结束后才能被唤醒。
资源队列在分析型的场景中应用得比较普遍，有些分析型语句需要的资源比较多，通过资源队列进行限制可以让每个语句依次快速完成，而不是每个语句特别慢地几乎同时完成。即使对于事务型的语句，队列限制也非常有帮助，可以防止突发的大量并发访问导致系统不稳定。队列限制提供了一个公平的机制，使排队等待的查询按照提交的先后顺序依次放行。有的用户担心Greenplum这样的分布式系统因为引入了分布式事务，会不会在处理短小的事务型语句时，由于分布式事务的开销导致延迟偏高。最近，Greenplum社区分析了这部分的代码逻辑，通过减少事务锁的冲突场景等手段优化锁的管理，并且合并了PostgreSQL后续版本的一些改进，例如大幅减少获取锁的开销，以及将多个事务的提交合并为一组一次写入事务日志等。经过一系列优化后，Greenplum处理一些短小查询时非常得心应手，我们对比了单机PostgreSQL 10和四节点的Greenplum 6-dev，在同样的120个并发情况下执行简单的事务型查询语句的情况，Greenplum并不输于PostgreSQL。例如，不使用索引时，Greenplum的TPS可以达到单机PostgreSQL的四倍。如下图所示，横坐标代表并发数，纵坐标代表TPS，黑色的线是PostgreSQL的数据，灰色的线是使用了资源组的Greenplum的TPS数据，可以看到，在这种情况下Greenplum有非常好的表现
