Am Sonntag, 18. September 2016 08:51:08 UTC+2 schrieb Noel Grandin:
> A secondary index is just a map from the index key -> list of row ids
> How are queries (e.g. "name like '%Eva%'") executed on such an index?
> Queries like that always require scanning over either the table itself, or if
> the column is present in an index, it is cheaper to scan over the index.
Thanks for the response, I really appreciate it. I thought that maybe there
would be a smarter way than using column value as key and the set of matching
rows as value, but apparently this is really the way to go.
There's one problem with this approach though. MVStore is a versioned data
store, right? Let's suppose that we are indexing a large set of rows (e.g. 1
million), and the column for the secondary index is an enumerated type, i.e. it
can only take one of 'n' values. Lets say the values are "red", "green" and
"blue". Our secondary index would use those three as keys, each one having a
looong list of matching row IDs as value. Now one row changes from "red" to
"green". I would have to re-write both lists in the secondary index all over
again due to a single, simple change. Lets say that we do want to keep old
versions and do not "garbage collect" them. In this case, we are writing lots
and lots of data to disk for reflecing very small changes. Is there a
better/smarter approach to this problem? How is MVStore/H2 currently adressing
You received this message because you are subscribed to the Google Groups "H2
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.