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 
this problem?

You received this message because you are subscribed to the Google Groups "H2 
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to