| ID | IEP-139 |
| Author | |
| Sponsor | |
| Created | 17 Jul 2025 |
| Status |
All rows stored in the grid are targeted with a concrete partition. Partitioning boosts performance by distributing both read and write operations, but currently sql and jdbc api`s are not aware about such distributions which leads to additional network interactions. If there are present duplicate requests with only a difference in transmitted parameters, client code can lazily (with some delay) calculate a concrete node which hosts requested or transmitted row(s) and makes a direct call there.
Initially let`s consider the scope of use cases this improvement can be applied to:
Consider a table like:
CREATE TABLE T (
id int,
col1 int DEFAULT -1,
col2 int,
PRIMARY KEY(id, col1, col2))
COLOCATE BY(col1, col2)
) |
// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.
// Links to discussions on the devlist, if applicable.
// Links to various reference documents, if applicable.
// Links or report with relevant JIRA tickets.