Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
Description
This task goal is to permit not sending metadata every time
What MySQL has done in version 8
MySQL has changed the protocol to permit skipping metadata for version 8.
see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html
and https://dev.mysql.com/worklog/task/?id=8134
In description MySQL task indicate some big improvement:
- METADATA_FULL : 3.48w TPS, Net send 113M
- METADATA_IGNORE: 13.8w TPS, Net send 30M
MySQL implementation send metadata (or not) according to resultset_metadata variable.
Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25)
When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY
Exchange format change
Column count packet
There is a "new metadata_follows flag"
* int<lenenc> column count
|
* int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows)
|
When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set).
be careful not to rely on mysql documentation that indicate them in a wrong order
COM_PREPARE response
* int<1> 0x00 COM_STMT_PREPARE_OK header
|
* int<4> statement id
|
* int<2> number of columns in the returned result set (or 0 if statement does not return result set)
|
* int<2> number of prepared statement parameters ('?' placeholders)
|
* string<1> -not used-
|
* int<2> number of warnings
|
* if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA
|
** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows)
|
}
|
if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped.
Requirement:
Connectors need metadata to parse resultset.
Proposal is to offer this functionality, but in a more modular way.
What do connectors need:
For first execute of a prepared statement:
- COM_STMT_PREPARE asked WITHOUT metadata.
- COM_STMT_EXECUTE asked WITH METADATA. metadata is cached
For next execute:
- COM_STMT_EXECUTE WITHOUT metadata. use cached metadata
There are two issues with not sending metadata each time:
- Metadata can change over time. Server already automatically reprepares internally, so it knows to resend the metadata even if the client asked not to send the metadata every time.
- commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time.
COM_STMT_PREPARE still need to have the possibility to ask for metadata (at least java need that possibility to have metadata (example) without any COM_STMT_EXECUTE execution)
For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY.
Client can then cache metadata and ask for COM_QUERY without metadata.
MySQL doesn't permits modularity, so client request have to add this information.
That can be either by:
- create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META
- changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format.
Attachments
Issue Links
- causes
-
MDEV-26271 Crashes in net_field_length since commit 295f3e4cfb4a8f132f36d53475efc92f2487aa97
-
- Closed
-
- is duplicated by
-
MDEV-14615 Avoid resend METADATA information in binary protocol if not changed
-
- Closed
-
- relates to
-
CONJ-840 support 10.6 new feature metadata skip
-
- Closed
-
-
CONJS-153 support Prepared statement with 10.6 new feature metadata skip
-
- Closed
-
-
MDEV-23913 Prepared statement column metadata can be wrong with UNION
-
- Stalled
-
-
MXS-3613 Support PS with metadata skip (i.e. MARIADB_CLIENT_CACHE_METADATA)
-
- Closed
-
-
R2DBC-10 support 10.6 new feature metadata skip
-
- Closed
-
-
ODBC-286 Very Poor Performance on Remote Connection
-
- Open
-
Activity
Field | Original Value | New Value |
---|---|---|
Key |
|
|
Project | MariaDB Connector/J [ 10301 ] | MariaDB Server [ 10000 ] |
Description |
This task goal is to permit not sending metadata every time for [COM_STMT_EXECUTE|https://mariadb.com/kb/en/library/com_stmt_execute/].
[COM_STMT_PREPARE |https://mariadb.com/kb/en/library/com_stmt_prepare/] already send metadata. Benchmarks shows a 10% to 20% performance change avoiding sending metadata. Proposition is to avoid sending metadata if there is no change. There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. 2 possible solution concerning protocol : * reusing COM_STMT_EXECUTE * create a new dedicated commands h3. reusing COM_STMT_EXECUTE add [flag|https://mariadb.com/kb/en/library/com_stmt_execute/#flag] AVOID_SENDING_METADATA with value 128 Current results protocol is : {noformat} Resultset metadata 1 Column count packet for each column (i.e column_count times) Column Definition packet if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} Without changing protocol, If metadata didn't change, [Column count packet|https://mariadb.com/kb/en/library/resultset/#column-count-packet] can be set to null value (0xFB) without column informations. Current results protocol would be : {noformat} Resultset metadata 1 Column count packet set to null if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} and if metadata changed, the actual format is still valid |
This task goal is to permit not sending metadata every time for [COM_STMT_EXECUTE|https://mariadb.com/kb/en/library/com_stmt_execute/].
[COM_STMT_PREPARE |https://mariadb.com/kb/en/library/com_stmt_prepare/] already send metadata. Benchmarks shows a 10% to 20% performance change avoiding sending metadata. Proposition is to avoid sending metadata if there is no change. There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. 2 possible solution concerning protocol : * reusing COM_STMT_EXECUTE * create a new dedicated commands h3. reusing COM_STMT_EXECUTE add [flag|https://mariadb.com/kb/en/library/com_stmt_execute/#flag] AVOID_SENDING_METADATA with value 128 Current results protocol is : {noformat} Resultset metadata 1 Column count packet for each column (i.e column_count times) Column Definition packet if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} Without changing protocol, If metadata didn't change, [Column count packet|https://mariadb.com/kb/en/library/resultset/#column-count-packet] can be set to 0 encoded on 3 bytes (0xFC0000) without column informations. Current results protocol would be : {noformat} Resultset metadata 1 Column count packet set to null if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} and if metadata changed, the actual format is still valid |
Description |
This task goal is to permit not sending metadata every time for [COM_STMT_EXECUTE|https://mariadb.com/kb/en/library/com_stmt_execute/].
[COM_STMT_PREPARE |https://mariadb.com/kb/en/library/com_stmt_prepare/] already send metadata. Benchmarks shows a 10% to 20% performance change avoiding sending metadata. Proposition is to avoid sending metadata if there is no change. There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. 2 possible solution concerning protocol : * reusing COM_STMT_EXECUTE * create a new dedicated commands h3. reusing COM_STMT_EXECUTE add [flag|https://mariadb.com/kb/en/library/com_stmt_execute/#flag] AVOID_SENDING_METADATA with value 128 Current results protocol is : {noformat} Resultset metadata 1 Column count packet for each column (i.e column_count times) Column Definition packet if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} Without changing protocol, If metadata didn't change, [Column count packet|https://mariadb.com/kb/en/library/resultset/#column-count-packet] can be set to 0 encoded on 3 bytes (0xFC0000) without column informations. Current results protocol would be : {noformat} Resultset metadata 1 Column count packet set to null if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} and if metadata changed, the actual format is still valid |
This task goal is to permit not sending metadata every time for [COM_STMT_EXECUTE|https://mariadb.com/kb/en/library/com_stmt_execute/].
[COM_STMT_PREPARE |https://mariadb.com/kb/en/library/com_stmt_prepare/] already send metadata. Benchmarks shows a 10% to 20% performance change avoiding sending metadata. Proposition is to avoid sending metadata if there is no change. There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. 2 possible solution concerning protocol : * reusing COM_STMT_EXECUTE * create a new dedicated commands h3. reusing COM_STMT_EXECUTE add [flag|https://mariadb.com/kb/en/library/com_stmt_execute/#flag] AVOID_SENDING_METADATA with value 128 Current results protocol is : {noformat} Resultset metadata 1 Column count packet for each column (i.e column_count times) Column Definition packet if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} Without changing protocol, If metadata didn't change, [Column count packet|https://mariadb.com/kb/en/library/resultset/#column-count-packet] can be set to 0 encoded on 3 bytes (0xFC0000) without column informations. Current results protocol would be : {noformat} Resultset metadata 1 Column count packet set to 0xFC0000 if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} and if metadata changed, the actual format is still valid |
Assignee | Diego Dupin [ diego dupin ] | Vladislav Vaintroub [ wlad ] |
Fix Version/s | 10.5 [ 23123 ] |
Link |
This issue is duplicated by |
Assignee | Vladislav Vaintroub [ wlad ] |
Fix Version/s | 10.5 [ 23123 ] |
Description |
This task goal is to permit not sending metadata every time for [COM_STMT_EXECUTE|https://mariadb.com/kb/en/library/com_stmt_execute/].
[COM_STMT_PREPARE |https://mariadb.com/kb/en/library/com_stmt_prepare/] already send metadata. Benchmarks shows a 10% to 20% performance change avoiding sending metadata. Proposition is to avoid sending metadata if there is no change. There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. 2 possible solution concerning protocol : * reusing COM_STMT_EXECUTE * create a new dedicated commands h3. reusing COM_STMT_EXECUTE add [flag|https://mariadb.com/kb/en/library/com_stmt_execute/#flag] AVOID_SENDING_METADATA with value 128 Current results protocol is : {noformat} Resultset metadata 1 Column count packet for each column (i.e column_count times) Column Definition packet if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} Without changing protocol, If metadata didn't change, [Column count packet|https://mariadb.com/kb/en/library/resultset/#column-count-packet] can be set to 0 encoded on 3 bytes (0xFC0000) without column informations. Current results protocol would be : {noformat} Resultset metadata 1 Column count packet set to 0xFC0000 if not (CLIENT_DEPRECATE_EOF capability set) EOF_Packet n resultset row EOF packet {noformat} and if metadata changed, the actual format is still valid |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol accordingly for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 in description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata or not according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY But connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: What does need connectors : - COM_STMT_PREPARE asked WITHOUT metadata. - COM_STMT_EXECUTE asked WITH METADATA. metadata is cached next query: - COM_STMT_EXECUTE WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if asked for no metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. COM_STMT_PREPARE still need to have the possibility to asked metadata (at least java need that possibility to have metadata without any COM_STMT_EXECUTE for example for https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData() without having executed COM_STMT_EXECUTE) for production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
Description |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol accordingly for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 in description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata or not according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY But connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: What does need connectors : - COM_STMT_PREPARE asked WITHOUT metadata. - COM_STMT_EXECUTE asked WITH METADATA. metadata is cached next query: - COM_STMT_EXECUTE WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if asked for no metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. COM_STMT_PREPARE still need to have the possibility to asked metadata (at least java need that possibility to have metadata without any COM_STMT_EXECUTE for example for https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData() without having executed COM_STMT_EXECUTE) for production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol accordingly for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 in description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata or not according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY But connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: What does need connectors : - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached next query: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if asked for no metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to asked metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
Description |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol accordingly for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 in description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata or not according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY But connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: What does need connectors : - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached next query: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if asked for no metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to asked metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol to permit skipping metadata for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 In description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata (or not) according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY But connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: What does need connectors : - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached next query: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if asked for no metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to asked metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
Description |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol to permit skipping metadata for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 In description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata (or not) according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY But connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: What does need connectors : - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached next query: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if asked for no metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to asked metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol to permit skipping metadata for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 In description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata (or not) according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: Connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. What does need connectors : For first prepare statement: - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached For next prepare statement: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if ask not to send metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to ask metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE execution) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
Fix Version/s | 10.6 [ 24028 ] |
Assignee | Oleksandr Byelkin [ sanja ] |
Priority | Major [ 3 ] | Critical [ 2 ] |
Assignee | Oleksandr Byelkin [ sanja ] | Vladislav Vaintroub [ wlad ] |
Description |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol to permit skipping metadata for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 In description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata (or not) according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: Connectors needs metadata to parse resultset. Proposition here is to offer this functionality, but in a more modular way. What does need connectors : For first prepare statement: - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached For next prepare statement: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There is 2 issues about not sending metadata each time : * Metadata can change in time. Server already automatically reprepare internally, so has the information to resend metadata next time even if ask not to send metadata. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to ask metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE execution) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits a modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
This task goal is to permit not sending metadata every time
h2. What MySQL has done in version 8 MySQL has changed the protocol to permit skipping metadata for version 8. see https://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html and https://dev.mysql.com/worklog/task/?id=8134 In description MySQL task indicate some big improvement: * METADATA_FULL : 3.48w TPS, Net send 113M * METADATA_IGNORE: 13.8w TPS, Net send 30M MySQL implementation send metadata (or not) according to [resultset_metadata|https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_resultset_metadata] variable. Associate capability is CLIENT_OPTIONAL_RESULTSET_METADATA (1UL << 25) When resultset_metadata = 0 (NONE) no metadata is send for COM_STMT_PREPARE/COM_STMT_EXECUTE/COM_QUERY h3. Exchange format change h4. [Column count packet|https://mariadb.com/kb/en/resultset/#resultset] There is a "new metadata_follows flag" {noformat} * int<lenenc> column count * int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) {noformat} When metadata_follows = 0x00, protocol skip column informations packet (continuing by an EOF_packet if CLIENT_DEPRECATE_EOF capability is not set or rows if CLIENT_DEPRECATE_EOF is set). be careful not to rely on [mysql documentation|https://dev.mysql.com/doc/dev/mysql-server/8.0.11/page_protocol_com_query_response_text_resultset.html] that indicate them in a wrong order h4. [COM_PREPARE response|https://mariadb.com/kb/en/com_stmt_prepare/#com_stmt_prepare-response] [COM_STMT_PREPARE_OK|https://mariadb.com/kb/en/com_stmt_prepare/#COM_STMT_PREPARE_OK]: {noformat} * int<1> 0x00 COM_STMT_PREPARE_OK header * int<4> statement id * int<2> number of columns in the returned result set (or 0 if statement does not return result set) * int<2> number of prepared statement parameters ('?' placeholders) * string<1> -not used- * int<2> number of warnings * if capabilities & CLIENT_OPTIONAL_RESULTSET_METADATA ** int<1> metadata_follows flag (0x00: No metadata, 0x01: metadata follows) } {noformat} if metadata is set to 0x00, column definition packet that decribe each parameter and each column are skipped. h2. Requirement: Connectors need metadata to parse resultset. Proposal is to offer this functionality, but in a more modular way. What do connectors need: For first execute of a prepared statement: - [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] asked WITHOUT metadata. - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] asked WITH METADATA. metadata is cached For next execute: - [COM_STMT_EXECUTE|https://mariadb.com/kb/en/com_stmt_execute/] WITHOUT metadata. use cached metadata There are two issues with not sending metadata each time: * Metadata can change over time. Server already automatically reprepares internally, so it knows to resend the metadata even if the client asked not to send the metadata every time. * commands like "SELECT ?" will have metadata type changing according to parameter. Metadata must then be send each time. [COM_STMT_PREPARE|https://mariadb.com/kb/en/com_stmt_prepare/] still need to have the possibility to ask for metadata (at least java need that possibility to have metadata ([example|https://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#getParameterMetaData()]) without any COM_STMT_EXECUTE execution) For production environment where DDL never change an option can be set on client level to use that same functionality for COM_QUERY. Client can then cache metadata and ask for COM_QUERY without metadata. MySQL doesn't permits modularity, so client request have to add this information. That can be either by: * create new commands COM_STMT_PREPARE_WITHOUT_META, COM_STMT_EXECUTE_WITHOUT_META and COM_QUERY_WITHOUT_META * changing existing COM_STMT_PREPARE, COM_STMT_EXECUTE and COM_QUERY format. |
Component/s | Binary Protocol [ 16120 ] |
Link | This issue relates to MDEV-23913 [ MDEV-23913 ] |
Status | Open [ 1 ] | Confirmed [ 10101 ] |
Status | Confirmed [ 10101 ] | In Progress [ 3 ] |
Assignee | Vladislav Vaintroub [ wlad ] | Oleksandr Byelkin [ sanja ] |
Status | In Progress [ 3 ] | In Review [ 10002 ] |
Assignee | Oleksandr Byelkin [ sanja ] | Vladislav Vaintroub [ wlad ] |
Status | In Review [ 10002 ] | Stalled [ 10000 ] |
Component/s | Prepared Statements [ 10804 ] | |
Component/s | Binary Protocol [ 16120 ] |
issue.field.resolutiondate | 2020-11-23 18:45:09.0 | 2020-11-23 18:45:09.843 |
Fix Version/s | 10.6.0 [ 24431 ] | |
Fix Version/s | 10.6 [ 24028 ] | |
Resolution | Fixed [ 1 ] | |
Status | Stalled [ 10000 ] | Closed [ 6 ] |
Link |
This issue causes |
Workflow | MariaDB v3 [ 95327 ] | MariaDB v4 [ 133929 ] |
Link | This issue relates to MENT-2165 [ MENT-2165 ] |