-
Notifications
You must be signed in to change notification settings - Fork 43
gh-1691 create an overview page about indexes #1847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is a draft for now so feel free to let me know if I missed something or wrote something incorrectly |
Co-authored-by: Nick Volynkin <[email protected]>
* just if you want to | ||
* if you think that HASH is faster with no performance metering | ||
* if you want to iterate over the data | ||
* for primary key |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to describe why
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't the first paragraph describe it well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first paragraph contradicts part below - if you really need that 2-5% performance improvement
(that means that for some tasks it's more appropriate than TREE) and if you save every byte on tuples
(to be honest, it looks like sneer) - yes, for some tasks it's important to save as much memory as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's rewrite if you really need that 2-5% performance improvement
as if you measure, that it will give you accountable performance improvement
if you save every byte on tuples (to be honest, it looks like sneer) - yes, for some tasks it's important to save as much memory as possible.
See nothing wrong. In that case HASH is appropriate. "Normal" users should not use hash: it gives in future more problems, than gains.
* :ref:`Making a functional index with space_object:create_index() <box_space-index_func>` | ||
* :ref:`Creating an index using field names instead of field numbers <box_space-field_names>` | ||
* :ref:`Creating an index using the path option for map fields (JSON-path indexes) <box_space-path>` | ||
* :ref:`Creating an index using the path option with [*] <box_space-path_multikey>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should call [*]
wildcard?
It's only suggestion and should be discussed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are several wildcard characters. https://support.microsoft.com/en-us/office/examples-of-wildcard-characters-939e153f-bd30-47e4-a763-61897c87b3f4
This one is called an asterisk. But I wouldn't bet that everyone remembers that.
Can we have other wildcards in paths, like ?
or #
?
Maybe we could say:
Creating an index using the path option with wildcard [*]
Co-authored-by: Ekaterina Kiryanova <[email protected]>
Co-authored-by: Ekaterina Kiryanova <[email protected]>
Co-authored-by: Ekaterina Kiryanova <[email protected]>
Here I tried to revise the information about indexes that we have in docs.
See implemented changes on these pages: