标签：语句 Pipeline -- PostgreSQL14 模式 发送 管道 SQL 客户端
libpq管道模式允许应用程序发送查询，而无需读取先前发送的查询的结果。利用管道模式，客户端将减少对服务器的等待，因为可以在单个网络事务中发送/接收多个查询/结果。
虽然管道模式提供了显著的性能提升，但使用管道模式编写客户端更加复杂，因为它涉及管理待处理查询的队列并查找哪个结果对应于队列中的哪个查询。
管道模式通常也会在客户端和服务器上消耗更多内存，尽管对发送/接收队列进行仔细和积极的管理可以缓解这种情况。无论连接是处于阻塞模式还是非阻塞模式，这都适用。
虽然管道API是在PostgreSQL14 中引入的，但它是一个客户端功能，不需要特殊的服务器支持，并且可以在任何支持v3扩展查询协议的服务器上工作
传统的批处理模式操作
管道模式
尽管在PostgreSQL14中引入，管道模式适用于任何当前支持的postgres版本，因为是在客户端使用的LIBPQ中，而不是PostgreSQL服务器本身！
不过利用管道模式需要使用“C”或能够直接与LIBPQ交互的等效编程语言。不幸的是，目前还没有太多的ODBC开发方式提供必要的钩子来利用这个增强的特性。因此，需要使用上述编程语言来设计和编码客户端-应用程序会话。
管道模式的工作原理
1.客户端与PostgreSQL服务端创建连接
2.客户端必须将连接切换成管道模式
3.进入管道模式后，sql请求被发送到server端
4.请求达到服务端后，语句立即被执行，结果被返回给客户端。客户端和服务端不需要进行ack确认
5.因为每个sql是顺序发送的。应用逻辑可以使用状态机或FIFO队列来处理请求
6.一旦所有异步语句都已执行并返回，客户端应用程序显式终止管道模式并将连接返回到其默认设置。
由于每个 SQL 语句本质上都是幂等的，因此由客户端逻辑来理解结果。发送 SQL 语句并提取彼此无关的结果是一回事，但是当处理具有某种程度相互依赖的逻辑结果时，会变得更加复杂。
可以将异步SQL语句捆绑为单个事务。但与所有事务一样，这些异步发送的SQL语句中的任何一个失败都将导致所有SQL语句回滚。
当然，API确实在管道故障的情况下提供错误处理。在 FATAL情况下，当管道本身失败时，客户端连接会收到错误通知，从而将剩余的排队操作标记为丢失。此后恢复正常处理，就好像管道已被客户端明确关闭，并且客户端连接保持活动状态。
·管道模式专为异步模式而设计。因此，同步模式是不可能的，这有点违背了管道模式的目的。
·一次只能发送一个SQL命令，即不允许多个SQL命令。
·不允许copy。
·在发送事务COMMIT的情况下：客户端在收到相应结果之前不能假定事务已提交。
·利用管道模式需要使用 C 或可以访问 libpq API 的语言进行编程。
标签：语句,Pipeline,--,PostgreSQL14,模式,发送,管道,SQL,客户端 来源： https://www.cnblogs.com/abclife/p/15865671.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。