You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Temporary tables do not read/write TiKV. For global temporary table, it has an empty snapshot data and for local temporary table, it keeps snapshot data in session. Currently, snapshot does not support reading from memory, so when reading a temporary table's snapshot record, we need to do some tricks.
For example in point get, when reading snapshot, just get the record from session (nil record if it is a global temporary table).
The above examples are not elegant, that is because we must add special codes in EVERY places where we need to access snapshot data. If we forget to do this, bug occurs.
A better practice is to make the kv.Snapshot more generic. That is, when the key is belongs to a temporary table, it read it from the session, otherwise from TiKV. After that, we can delete a lot of codes like if tblInfo.TempTableType != model.TempTableNone and to make a unified snapshot access for both temporary and normal table.
One difficulty to achieve it is that Snapshot object does not have the context of the table currently reading. So it can not infer whether to get the data from memory or not. In fact, snapshot does not have any concept for table, it is a more underlaying utility to access bytes key and values. We need to introduce some different abstractions to snapshot to make it.
I posted a draft here: tikv/client-go#262 to make KVSnapshot able to read data from memory. It introduces a methods SetSortedCustomKeyRetrievers to set the ranges for custom reading.
I posted another draft in tidb: #26948 to use above Snapshot to access temporary table snapshot data.
Enhancement
Temporary tables do not read/write TiKV. For global temporary table, it has an empty snapshot data and for local temporary table, it keeps snapshot data in session. Currently, snapshot does not support reading from memory, so when reading a temporary table's snapshot record, we need to do some tricks.
For example in point get, when reading snapshot, just get the record from session (nil record if it is a global temporary table).
tidb/executor/point_get.go
Lines 405 to 429 in 300f159
For batch_point_get, we make a custom snapshot
temporaryTableSnapshot
implementskv.Snapshot
to read temporary session data.tidb/executor/batch_point_get.go
Lines 149 to 169 in 300f159
The above examples are not elegant, that is because we must add special codes in EVERY places where we need to access snapshot data. If we forget to do this, bug occurs.
A better practice is to make the
kv.Snapshot
more generic. That is, when the key is belongs to a temporary table, it read it from the session, otherwise from TiKV. After that, we can delete a lot of codes likeif tblInfo.TempTableType != model.TempTableNone
and to make a unified snapshot access for both temporary and normal table.One difficulty to achieve it is that Snapshot object does not have the context of the table currently reading. So it can not infer whether to get the data from memory or not. In fact, snapshot does not have any concept for table, it is a more underlaying utility to access bytes key and values. We need to introduce some different abstractions to snapshot to make it.
Steps:
RangedKVRetriever
inclient-go
to combine KeyRange and Retriever and provide method to intersect two ranges #27541TemporaryTableDDL
to mange temporary table ddl opeartions. #27775temptable
package #27817Below pull requests are outdated and not used by new design
sortedRetrievers
to manage custom data fetch #27626The text was updated successfully, but these errors were encountered: