[erlang-questions] ordered_set and range queries

[Ulf Wiger]

In order to limit the scan, you need to make sure the first part
of the key pattern is bound/constant. In this case, only the record
tag is constant, but it is the same for all records in the table...

There is no analysis in place that determines whether the guard
pattern could warrant a limited scan.

For the kind of test you're doing here, an alternative would be
to use mnesia:dirty_next(test, {test,Start,Floor}), where Floor
is something that you know to be smaller than any actual value
in that position in the table. Then you could keep doing next()
until you hit the upper bound.

Unless the table is really very large, this is likely to be
more costly than doing the select, though.

BR,
Ulf W

On 05/08/2010 07:21 PM, Garrett Smith wrote:
> I'm playing around with the performance characteristics of using
> type=ordered_set in mnesia.
> 
> My record looks like #test{time, val} where time is an integer
> timestamp (e.g. epoch milliseconds).
> 
> When I run this:
> 
> mnesia:dirty_select(test, [{{test, '$1', '$2'}, [{'>=', '$1', Start},
> {'=<', '$1', End}], [['$1', '$2']]}]]
> 
> I get the same basic timings regardless of the result set size. I.e. I
> suspect there's a full table scan in every case.
> 
> Just to verify, I ran the same tests on a type=set table and got the
> same basic timings.
> 
> Is there a way to perform that select that takes advantage of the sorted key?
> 
> Garrett
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com