Bug #90703 Have Client/Server protocol optionally return blocks of rows in single packet
Submitted: 30 Apr 2018 18:46 Modified: 17 Jul 2020 13:59
Reporter: Jason Rahman Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Connection Handling Severity:S4 (Feature request)
Version: OS:Any
Assigned to: CPU Architecture:Any

[30 Apr 2018 18:46] Jason Rahman
Description:
Change the resultset format so that instead of returning a single row per MySQL protocol packet (or one row in multiple packets for large rows), return a special row-block packet that contains multiple rows in a single MySQL protocol packet.

How to repeat:
Documentation indicates this is the format for the resultsets.

Suggested fix:
Change the resultset format so that instead of returning a single row per MySQL protocol packet (or one row in multiple packets for large rows), return a special row-block packet that contains multiple rows in a single MySQL protocol packet
[15 Jun 2020 12:30] MySQL Verification Team
Hi Mr. Rahman,

We would very much like to consider this feature request.

However, your suggestion of the new format is insufficient. We would like to see how would it look like in detail.

Also, we have to maintain compatibility with all existing client versions, so how can we do it without breaking the compatibility ????
[16 Jul 2020 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[16 Jul 2020 18:53] Jason Rahman
For backwards compatibility, the idea would be to use a client capability flag to negotiate this between the server and the client to ensure that both agree on the new format.

On the format, the idea here is that today MySQL forwards each row in one or more length encoded packet:
[mysql_pkt1][length][row_content] [mysql_pkt2][length][row_content] ....

This means that an L7 proxy must read each length encoded packet. For resultsets with many small rows, the overhead to read in each small packet and parse that out is very non-trival. Instead, and alternative format is possible that packs multiple rows per MySQL protocol packet.

An example of how multiple small rows would be packed into a single MySQL protocol packet:
[mysql_pkt1][packet_length][row1_length][row1_content][row2_length][row2_content]....

Very long rows would still need to be split across multiple MySQL protocol packets:
[mysql_pkt1][packet_length][row1_length][row1_content] [mysql_pkt2][packet_length][row1_content] [mysql_pkt3][packet_length][row1_content]
[17 Jul 2020 12:52] MySQL Verification Team
Hi Mr. Rahman,

Let us summarise what you are asking for. Correct us if necessary.

You would like us to introduce a completely new protocol, so that we would need to maintain two different protocols for the next N years.

On the other hand, what we have today is a possibility to configure a packet size, which would enable us to achieve the same, or almost the same, effect, without any new protocol.
[17 Jul 2020 13:59] MySQL Verification Team
Hi,

After further analysis, we concluded that this is a valid feature request.

Verified as a feature request.