OSQL bundling

[riverszhang89]

A write transaction is translated to a sequence of OSQL operations. Each OSQL operation is shipped to the master from a replicant. When an OSQL packet arrives at the master, it is saved to a temptable. After the entire sequence is received by the master (indicated by OSQL_DONE), all of its OSQL operations are fetched from the temptable and are processed in the block processor.

OSQL bundling is an optimization where instead of individually shipping OSQL operations, saving them to a temptable, and reading them back later on, they are bundled: packets are first buffered on a replicant, forming a "bundle". If a bundle becomes too large, it is shipped to the master and a new empty bundle is started. When the transaction is about to end (either commit or rollback), the replicant ships the last bundle to the master and waits for a response from the master.

There are 3 advantages of the optimization. Firstly, network overhead is cut back since there will be fewer network packets. Secondly, temptable overhead on the master is mostly eliminated, except for very large transactions where more than one bundle is needed, in which case the temptable overhead is still reduced significantly. Thirdly, it matches the processing model of transaction levels higher than blocksql, where a shadow table already holds onto OSQL operations till the end of a transaction.

However there is a disadvantage of the optimization: it does not work with socksql-reorder. socksql-reorder needs to pre-process and sort each OSQL operation, which beats the purpose of OSQL bundling. Because of this, OSQL bundling is disabled in blocksql mode if reorder is enabled.

[riverszhang89]

cdb2test   Jun 22 13:39:16 2021  in-comdb2db osqlv12.R20210622.4

The pull request is now ready for review.