PG的管道模式如何工作
今天给大家介绍PG引入的一个很酷的特性--管道模式。
什么是管道模式呢？管道模式允许应用程序发送查询，而不用读取先前发送查询的结果。一句话，它允许在单个网络事务中发送和接收多个查询和结果，从而显著提高性能。
正如所有好主意一样，都有一个范例：人们可以使用应用程序代码来模拟这种行为。在客户端与服务之间异步通信了一段时间，或者称之为“批处理模式”。有许多现有的解决方案以异步方式处理多个查询。例如PgJDBC多年来一直使用标准JDBC批处理接口支持批处理模式。当然，还有老的可靠备用dblink。
流水线模式的不同之处在于它提供了一个开箱即用的解决方案，大大降低了应用程序代码处理客户端--服务端会话的复杂性。
传统的批处理模式
流水线模式
尽管在PG14中引入，管道模式适用于当前任何版本。因为增强在客户端使用的LIBPQ中，而不是服务端本身。
现在是坏消息了：利用流水线模式和需要使用“C”或能够之间与LIBPQ交互的编程语言。不幸的是，目前还没有太多的ODBC开发方式提供必要的钩子来利用这个增强的特性。因此，需要使用上述编程语言来涉及和编程客户端--应用程序会话。
提示：对于某些人来说，这是一个为自己命名并创建一个方便的LIBPQ管道模式接口的号方法。
怎么运行
现在来探讨下这个机制是如何工作的。
保持简单：
1）客户端首先连接到PG服务
2）客户端连接必须切换到管道模式
3）一旦进入管道模式，SQL语句就会被发送到服务
4）达到服务后，语句立即执行并将结果发送回客户端，即不需要客户端/服务端确认
5）因为每个SQL语句都是按顺序发送，所以应用程序逻辑可以使用状态机或者利用FIFO队列来处理结果
6）一旦所有异步语句都已执行并返回，客户端应用程序显式终止管道模式并将连接返回到默认设置
由于每个SQL语句本质上都是幂等性的，因此由客户端逻辑来解释结果。发送SQL语句并提取彼此无关的结果是一回事，但当处理具有某种程度上互相依赖的逻辑结果时，会变得更加复杂。
可以将异步SQL语句捆绑为单个事务。但与所有事务一样，这些异步发送的SQL语句中任何一个失败都将导致所有SQL语句回滚。
当然API确实在管道故障情况下提供错误处理。在FATAL情况下，当管道本身失败时，客户端连接会接收到错误通知，从而将剩余的排队操作标记为丢失。此后恢复正常处理，就好像管道已被客户端明确关闭，并且客户端连接保持活动状态。
细节
对于C程序员来说，这里有一些参考资料：
1）如前所述，可以针对多个版本的PG使用此功能，但尽在PG14及以后版本进行了描述
2）PG14源代码：src/test/modules/libpq_pipeline/libpq_pipeline.c提供了一个执行SELECT函数调用的简单例子
注意
1) 流水线模式专为异步模式而涉及，因此同步模式不可使用，这有点违背了流水线模式的目的。
2) 一次只能发送一个SQL命令，不允许多个SQL
3) 不允许复制
4) 在发送事务COMMIT情况下：客户端在收到相应结果前，不能假定事务已提交
5) 利用流水线模式需要使用C或者可以访问libpsq api的语言进行编程
参考
https://stackoverflow.com/questions/65469533/where-is-query-pipelining-in-libpq
原文
https://www.percona.com/blog/how-postgresql-pipeline-mode-works/
