[erlang-questions] Processes stuck in ets:select_trap

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Mon Oct 26 13:50:27 CET 2015


It depends on how your filter function works:

Create a table:

2> ets:new(foo, [named_table, {keypos, 1}]).
foo

Fill the table so we can measure lookup differences in time:

3> ets:insert(foo, [{K, K+1} || K <- lists:seq(1, 1000000)]).
true

Create a point-query match spec:

4> MS = ets:fun2ms(fun({3, V}) -> V end).
[{{3,'$1'},[],['$1']}]

Run a query with this matchspec:

5> timer:tc(fun() -> ets:select(foo, MS) end).
{25,[4]}

Create another match-spec where you don't match directly on the key:

6> MS2 = ets:fun2ms(fun({K, V}) when K == 3 -> V end).
[{{'$1','$2'},[{'==','$1',3}],['$2']}]

Now time this one:

7> timer:tc(fun() -> ets:select(foo, MS2) end).
{177663,[4]}

As you can see, the MS2 variant requests elements of the form {$1, $2} and
then proceeds to filter them via $1 == 3, which is much more expensive than
the first one which requests data of the form {3, $2} and then needs no
filtering.


On Mon, Oct 26, 2015 at 1:40 PM, Max Lapshin <max.lapshin@REDACTED> wrote:

> Correct me if I'm wrong, but ets:select is always a full table scan.
>
>


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151026/35c24547/attachment.htm>


More information about the erlang-questions mailing list