[erlang-questions] Mnesia Secondary Indexes

[Evans, Matthew]

Hi,

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:

KeyAsInteger

Became a tuple:

{KeyAsInteger,RangeValue}

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.



-----Original Message-----
From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Tom McNulty
Sent: Tuesday, July 21, 2009 3:14 PM
To: erlang-questions@REDACTED
Subject: [erlang-questions] Mnesia Secondary Indexes

Hi all,

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?

- Tom


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org