Thanks, fix committed.
The problem as actually not to do with memory tables, it had to do with
different cardinal types in the underlying table vs the query column.
In this case, the underlying column was a LONG, but the query key was an
INT, which led to incorrect results.
On 2013-08-08 12:36, Steve McLeod wrote:
Hi Thomas and all,
Below is a reproducible test case showing that hash index doesn't
reliably work. This problem exists in H2 1.3.173.
Let me know if you need further information.
Regards,
Steve
-- reproducible test case that demonstrates that hash indexes are
broken with memory tables
-- create test table
drop table if exists hash_index_test;
create memory table hash_index_test as select x as id, x%10 as data from (
SELECT * FROM SYSTEM_RANGE(1, 100)
);
-- create default index and query
-- this returns 10 as expected
create index idx1 on hash_index_test(data);
select count(*) from hash_index_test where data = 1;
-- create hash index and query
-- this should return 10 but returns 0
drop index idx1;
create hash index idx2 on hash_index_test(data);
select count(*) from hash_index_test where data = 1;
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
