-
Notifications
You must be signed in to change notification settings - Fork 344
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
Composite index of "STRING" type #1754
Comments
The problem is related to a way how the index key is created during the upsert. First of all the ingredients of the index are encoded. For varchar type the value is encoded in a way that it first gets bytes from the string, then value is filled with 0 bytes and ad the end there is simply the lenght of the string. With the default settings encoded varchar ends up having 517 bytes. Later when the final key is created all the ingredients are concatenated. If we have 2 string columns used to build the index we end up having more than 517+517 bytes. In next steps there is a check if the key is not exceeding the maximum allowed size which defaults to 1024. And here is "kaboom". First of all knowing the length limitations the solution could be to build a key from real characters (without filling with zero bytes). But of course this solution wouldn't be correct. This is because in such a way "foo" (from column1), "bar" (from column2) wouldn't be distinguishable from "fo" (from column1), "obar" (from column2). Another solution is to use a separator byte between columns in index and ignore the fill with zero bytes but still a user can really insert long strings (as long as 512 bytes) and we'll hit the same issue. |
Good catch. |
Creating composing index on document collections is not currently working with STRING types: it let you create the index, but the an error occurs when a document is inserted.
The text was updated successfully, but these errors were encountered: