I'm just looking at the created indexes and getting with
SELECT sql, index_class
FROM information_schema.indexes
WHERE table_name = 'USER' AND primary_key = FALSE
this result
SQL
http://localhost:8082/query.do?jsessionid=4543ce724e0a897791e57bfcdcc8807b#
INDEX_CLASS
We only have real hash indexes for in-memory databases.
For persistent databases, the hash qualifier doesn't do anything.
What did you think a persistent hash-index would look like, if not a b-tree ?
On 2014-05-16 13:28, Martin Grajcar wrote:
It puzzles me that the PageBtreeIndex gets used
Thank you for the quick answer. My though was that I don't need any
ordering so I'd go for the faster option. But actually I don't care.
How should a persistent hash-index look like? Maybe something like
Clojure's HashMap, maybe an optimized subclass of PageBtreeIndex? Am I a
database writer? :D
Thanks Noel.
On Thursday, 8 August 2013 13:44:02 UTC+2, Noel Grandin wrote:
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
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
--
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
