Mnesia secondary indexes and selects

[Leonard B]

Thanks Ulf,

Primary reason I was asking is that I'm working on a foundationdb backend
(mnesia_fdb) for mnesia (I believe based on your eleveldb backend).

With fdb being an ordered key/value store I hoped to take advantage of
range based selects over index tables rather than full scans wherever
possible.

My initial expectation was there would be an index scan wherever an index
existed. But it looks like I'll probably have to parse the
matchspecs/guards to handle this myself. Hence my interest in any prior
work on any planner.

Thanks,
Leonard



On Thu, Jun 18, 2020, 12:35 Ulf Wiger <ulf@REDACTED> wrote:

> The select() function is quite low-level, and maps directly to the
> corresponding select functions in ets and dets.
> The analysis gets a bit too complex to perform in that context, since
> the call is expected to be fast.
>
> If you want to perform more complex queries, you may want to look into QLC.
>
> There aren't really that many examples around, but the Learn You Some
> Erlang book
> has some in the Mnesia chapter.
> https://learnyousomeerlang.com/mnesia
>
> BR,
> Ulf W
>
> Den tors 18 juni 2020 kl 17:03 skrev Leonard B <
> leonard.boyce@REDACTED>:
> >
> > While working on understanding secondary indexes in mnesia to add
> > support for them in another project I was a bit surprised to see that
> > secondary indexes are not used in 'select' operations unless the value
> > is bound in the head pattern.
> >
> > Hopefully someone with deeper knowledge can either tell me I'm wrong,
> > or explain why that is the case.
> >
> > For example:
> > ```
> > 1> mnesia:create_schema([node()]).
> > ok
> > 2> mnesia:start().
> > ok
> > 3> rd(test, {i, v}).
> > test
> > 4> mnesia:create_table(test,
> > [{disc_copies,[node()]},{type,ordered_set},{record_name,
> > test},{attributes,record_info(fields,test)}, {index, [#test.v]}]).
> > {atomic,ok}
> > 5>
> > 5> mnesia:dirty_write(test, #test{i = 1, v = one}).
> > ok
> > 6> mnesia:dirty_write(test, #test{i = 2, v = two}).
> > ok
> > 7> mnesia:dirty_write(test, #test{i = 3, v = three}).
> > ok
> > 8>
> > 8> mnesia:dirty_select(test, [{#test{v = two, _ = '_'},[],['$_']}]).
> > remote_dirty_select USING index
> > [#test{i = 2,v = two}]
> > 9> mnesia:dirty_select(test, [{#test{v = '$1', _ = '_'},[{'=:=', '$1',
> > two}],['$_']}]).
> > remote_dirty_select NOT using index
> > [#test{i = 2,v = two}]
> >
> > ```
> >
> > Was there some historical reason for this?
> >
> > Also curious if there has ever been any attempt to write a planner to
> > take advantage of secondary indexes.
> >
> > Thanks,
> > Leonard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200618/c013c963/attachment.htm>