Skip to content

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

Merged
merged 7 commits into from
Feb 24, 2021
Merged

Conversation

Onvember
Copy link
Contributor

@Onvember Onvember commented Feb 19, 2021

@Onvember
Copy link
Contributor Author

This is a draft for now so feel free to let me know if I missed something or wrote something incorrectly

@Onvember Onvember requested a review from olegrok February 24, 2021 10:42
* 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
Copy link

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

Copy link
Contributor Author

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?

Copy link

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.

Copy link

@Mons Mons Mar 3, 2021

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>`
Copy link

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.

Copy link
Contributor

@NickVolynkin NickVolynkin Mar 5, 2021

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 [*]

@Onvember Onvember merged commit ac45261 into latest Feb 24, 2021
@Onvember Onvember deleted the onvember/gh-1691 branch February 24, 2021 12:59
NickVolynkin added a commit that referenced this pull request Mar 15, 2021
NickVolynkin added a commit that referenced this pull request Mar 15, 2021
Onvember pushed a commit that referenced this pull request Mar 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants