<div dir="auto">Thanks Ulf,<div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Leonard</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020, 12:35 Ulf Wiger <<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The select() function is quite low-level, and maps directly to the<br>
corresponding select functions in ets and dets.<br>
The analysis gets a bit too complex to perform in that context, since<br>
the call is expected to be fast.<br>
<br>
If you want to perform more complex queries, you may want to look into QLC.<br>
<br>
There aren't really that many examples around, but the Learn You Some<br>
Erlang book<br>
has some in the Mnesia chapter.<br>
<a href="https://learnyousomeerlang.com/mnesia" rel="noreferrer noreferrer" target="_blank">https://learnyousomeerlang.com/mnesia</a><br>
<br>
BR,<br>
Ulf W<br>
<br>
Den tors 18 juni 2020 kl 17:03 skrev Leonard B <<a href="mailto:leonard.boyce@lucidlayer.com" target="_blank" rel="noreferrer">leonard.boyce@lucidlayer.com</a>>:<br>
><br>
> While working on understanding secondary indexes in mnesia to add<br>
> support for them in another project I was a bit surprised to see that<br>
> secondary indexes are not used in 'select' operations unless the value<br>
> is bound in the head pattern.<br>
><br>
> Hopefully someone with deeper knowledge can either tell me I'm wrong,<br>
> or explain why that is the case.<br>
><br>
> For example:<br>
> ```<br>
> 1> mnesia:create_schema([node()]).<br>
> ok<br>
> 2> mnesia:start().<br>
> ok<br>
> 3> rd(test, {i, v}).<br>
> test<br>
> 4> mnesia:create_table(test,<br>
> [{disc_copies,[node()]},{type,ordered_set},{record_name,<br>
> test},{attributes,record_info(fields,test)}, {index, [#test.v]}]).<br>
> {atomic,ok}<br>
> 5><br>
> 5> mnesia:dirty_write(test, #test{i = 1, v = one}).<br>
> ok<br>
> 6> mnesia:dirty_write(test, #test{i = 2, v = two}).<br>
> ok<br>
> 7> mnesia:dirty_write(test, #test{i = 3, v = three}).<br>
> ok<br>
> 8><br>
> 8> mnesia:dirty_select(test, [{#test{v = two, _ = '_'},[],['$_']}]).<br>
> remote_dirty_select USING index<br>
> [#test{i = 2,v = two}]<br>
> 9> mnesia:dirty_select(test, [{#test{v = '$1', _ = '_'},[{'=:=', '$1',<br>
> two}],['$_']}]).<br>
> remote_dirty_select NOT using index<br>
> [#test{i = 2,v = two}]<br>
><br>
> ```<br>
><br>
> Was there some historical reason for this?<br>
><br>
> Also curious if there has ever been any attempt to write a planner to<br>
> take advantage of secondary indexes.<br>
><br>
> Thanks,<br>
> Leonard<br>
</blockquote></div>