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
More optimizations can be integrated to improve the performance of the index data structure, like fingerprints, stashed buckets, balanced insertions, and displacement in presented in Dash1.
Separate the hash index building into a separate physical operator.
Add support of CREATE INDEX, and alter node table to define primary key (defining the primary key when defining a node table is no longer required, but require the primary key exists when defining a rel table over it).
Merge hash indexes into a single file. (to be debated whether directly merged into data.kz or keep a index.kz file).
Problems
There are several issues in terms of usability and performance with our hash index.
Performance wise:
It doesn't scale to multiple threads.It doesn't support rehash dynamically, thus, the CSV reader is forced to count exact num of tuples, which is often slow.Per-index Memfile Locking Contention #2626Usability wise:
It wasn't coded in a way to scale to different data types for keys.(Support most simple types in the hash index #2728)It limits string keys to be equal or less than 4KB.(fixed in Increase the length limit for primary key strings to 256KB #2689)TODOs
CREATE INDEX
, and alter node table to define primary key (defining the primary key when defining a node table is no longer required, but require the primary key exists when defining a rel table over it).data.kz
or keep aindex.kz
file).Footnotes
Dash: Scalable Hashing on Persistent Memory ↩
The text was updated successfully, but these errors were encountered: