postgresSQL Extended Query执行过程和sharding-proxy的处理

pg Extended Query

PostgreSQL: Documentation: 15: 55.2. Message Flow

多个阶段，可复用

1. Parse → DESCRIBE statement → SYNC

   1. Parse 解析， 将 sql 文本字符串，解析成 named preparedStatement 语句（生命周期随session） 占位符和参数类型
   2. Describe 获取元数据，返回 pst 参数描述符 parameterDescription 和 结果集的行描述符 RowDescription
      由于此时 还没执行 Bind，还未将语句传输到backend 执行，RowDescription中列的传输格式 codec format 还是0 ； 参数的类型应该也只是根据客户端传到 frontend 指定的类型来的？
   3. Sync 发完一串 extended messages 后需要发一个 sync 表示结束, 服务端一起处理；
      针对 sync 消息，服务端返回是否在事务中执行的状态 ‘T’ 在事务内， ‘I’ 不在事务内

2. BIND → DESCRIBE portal → EXECUTE → SYNC

• bind 绑定阶段 创建好一个可执行的 portal, 包括参数元数据、返回结果集的元数据 （row 字段的pg类型 typeOid, 类型长度、 传输方式 0-text, 1-binary 等) 参数值
• DESCRIBE portal；此时是发到 backend 来获取元数据的，入参和查询结果的元数据 才是真实的
• execute 阶段 执行并获取结果集， 客户端可以根据上一步 describe portal 拿到的 rowDescription 中列的 format 来决定是用 0-text 还是 1-binary 要求服务端对参数和查询结果集中的字段值进行 format 后传输

同一个session里边，步骤一执行过后 如果是 named portal ，后续就可以直接执行步骤二

步骤一执行完后, frontend session 缓存好命名 pst， 下次同一个session再执行就能直接 走步骤二就可以了

sharding-proxy 执行日志

步骤一

‘P’ Parse stmtcache_1 sql

‘D’ ‘S’ Describe preparedStatement

[DEBUG] 2023-04-07 17:16:53.166 [nioEventLoopGroup-3-3] o.a.s.db.protocol.codec.PacketCodec - Read from client a3f6d846 :
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 00 00 00 aa 73 74 6d 74 63 61 63 68 65 5f 31 |**P**....stmtcache_1|
|00000010| 00 53 45 4c 45 43 54 20 22 69 64 22 2c 22 73 74 |.SELECT "id","st|
|00000020| 75 64 65 6e 74 5f 6e 61 6d 65 22 20 46 52 4f 4d |udent_name" FROM|
|00000030| 20 22 74 5f 73 74 75 64 65 6e 74 5f 69 6e 66 6f | "t_student_info|
|00000040| 22 20 57 48 45 52 45 20 22 74 5f 73 74 75 64 65 |" WHERE "t_stude|
|00000050| 6e 74 5f 69 6e 66 6f 22 2e 22 69 64 22 20 3d 20 |nt_info"."id" = |
|00000060| 24 31 20 41 4e 44 20 22 74 5f 73 74 75 64 65 6e |$1 AND "t_studen|
|00000070| 74 5f 69 6e 66 6f 22 2e 22 69 64 22 20 3d 20 24 |t_info"."id" = $|
|00000080| 32 20 4f 52 44 45 52 20 42 59 20 22 74 5f 73 74 |2 ORDER BY "t_st|
|00000090| 75 64 65 6e 74 5f 69 6e 66 6f 22 2e 22 69 64 22 |udent_info"."id"|
|000000a0| 20 4c 49 4d 49 54 20 31 00 00 00 44 00 00 00 11 | LIMIT 1...**D**....|
|000000b0| 53 73 74 6d 74 63 61 63 68 65 5f 31 00 53 00 00 |**S**stmtcache_1.**S**..|
|000000c0| 00 04                                           |..              |
+--------+-------------------------------------------------+----------------+

请求报文 解析成对应的 packet 对象 xxPacket，并创建对应的执行器 xxExecutor

执行结果

此时 rowDescription, dataFormat都是0

步骤二

‘B’ Bind

‘D’ + ‘P’ Describe porta

‘E’ Execute

‘S’ Sync

[DEBUG] 2023-04-07 17:16:53.304 [nioEventLoopGroup-3-3] o.a.s.db.protocol.codec.PacketCodec - Read from client a3f6d846 :
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 42 00 00 00 37 00 73 74 6d 74 63 61 63 68 65 5f |**B**...7.stmtcache_|
|00000010| 31 00 00 02 00 01 00 01 00 02 00 00 00 08 00 00 |1...............|
|00000020| 00 00 00 00 00 16 00 00 00 08 00 00 00 00 00 00 |................|
|00000030| 00 16 00 02 00 01 00 00 44 00 00 00 06 50 00 45 |........**D**....P.**E**|
|00000040| 00 00 00 09 00 00 00 00 00 53 00 00 00 04       |.........**S**....  |

报文解析，和对应执行器构建

响应报文

RowDescription 响应结果集的行描述符，DataRowPacket 响应行数据

列 id ，值是 binary 格式 对应 columnDescription 的 dataFormat = 1 (binary)