thanks for the links an tips. It gives me some good direction. I will report soon my findings as well :)<br><div class="gmail_quote"><div dir="ltr">On Sat 4 Jul 2015 at 14:45 Jachym Holecek <<a href="mailto:freza@circlewave.net">freza@circlewave.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"># Benoit Chesneau 2015-07-04:<br>
> Does anyone have links or knows how ets:select is performing? Not that I<br>
> have any issue with it right now, but I am wondering if there are already<br>
> some benchmarks or known limits about it I should be aware.<br>
><br>
> Also how does it works internally, the doc let me think it is traversing<br>
> all the keys but not sure about it.<br>
<br>
The ordered_set variety should be doing a prefix scan whenever it can,<br>
rather than full table scan. Not sure how strong it is at figuring out<br>
more general range-scans.<br>
<br>
Some discussion is here:<br>
<br>
  <a href="http://www.erlang.org/doc/efficiency_guide/tablesDatabases.html" rel="noreferrer" target="_blank">http://www.erlang.org/doc/efficiency_guide/tablesDatabases.html</a><br>
<br>
The ets:select/3 + ets:select/1 variants can help you place upper bounds<br>
on some of the costs, a bit indirectly perhaps. That's more on the safety<br>
engineering side of things I suppose.<br>
<br>
Breaking things into multiple tables of appropriate types and layouts as<br>
suggested by Max is sound advice -- once you have a solid data model and<br>
understand your access patterns well.<br>
<br>
HTH,<br>
        -- Jachym<br>
</blockquote></div>