Mnesia secondary indexes and selects

[Ulf Wiger]

Yes, feel free to copy the aporoach used in mnesia_rocksdb et al.

My approach there was to use sext prefix encoding to bound the iteration,
then use ets:match_spec_run() for filtering.

BR,
Ulf W

Den tors 18 juni 2020 19:52Leonard B <leonard.boyce@REDACTED> skrev:

> 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/f18b99c4/attachment.htm>