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 [?] I guess the access time is strongly dominated by the disk access and there's no way to reduce their number, and there's not much to gain. Otherwise you've implemented it already. So everything's fine. Regards, Martin. On Fri, May 16, 2014 at 1:31 PM, Noel Grandin <[email protected]> wrote: > 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 for both the normal and >> hash indexes. It's a single column index and the >> column is Nullable Unicode VARCHAR(255). >> >> > -- > 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/d/optout. > -- 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/d/optout.
