[erlang-questions] Mnesia Secondary Indexes
Tue Jul 21 22:34:43 CEST 2009
I recently faced a similar issue to this. I wanted to do a range-based query on a table (created as a bag) where each primary key could contain a large number of records (10K or so). I decided against using a secondary index as a key, but instead searched using a select, with a primary key and specifying a guard to do the range query.
As expected, these queries took a long time.
To overcome this performance issue I changed the table from a bag to a set and used a modified gb_tree module that returned a reference to the range.
For example, the old key of:
Became a tuple:
The modified gb_tree accepted any value in the query, and would return the "closest" match. I could then use this as the RangeValue in the query to the tuple.
From: [mailto:] On Behalf Of Tom McNulty
Sent: Tuesday, July 21, 2009 3:14 PM
Subject: [erlang-questions] Mnesia Secondary Indexes
When adding an index to a table field, it appears to me (without
looking at the source), that the indexing method is hash based. While
this is optimal for fast secondary key lookups and join operations, it
does not speed up range based queries. After going through all
available manuals, I'm quite certain it's not possible to use tree-
based indexing on a field, but please correct me if I'm wrong.
My question finally, are there an plans to add tree-based indexing to
mnesia? And in the meantime, are there any existing projects which
hack on this support?
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
More information about the erlang-questions