Message Routing Paradigms
Sun Dec 15 01:19:51 CET 2002
Thank you; yes I saw those. I think my problem is different, however.
Rather than having a table of values that I want to match with a single
search pattern, I have a table of search patterns that I want to match
with a single value.
In other words:
Given [a,b,c], ['_',b,c], and [x,y,z] as patterns I want to find out if
the value [a,b,c] matches anything. I have a database of patterns. I
do not have a database of values.
I have 1000s of patterns where one is added and dropped once a second
and I have 10,000 values per second. So the map structure changes once
a second and I search through it 10,000 times per second.
From: Wiger Ulf [mailto:]
Sent: Saturday, December 14, 2002 2:37 PM
To: Eric Newhuis
Subject: Re: Message Routing Paradigms
On Dec 14, Eric Newhuis <> wrote:
>The subscribable record sets are defined with a simple pattern matching
>language that matches variable-length lists of Erlang values or
>wildcards. So, for example, a subscriber could choose to subscribe to
>either [a,b,c,d], ['_',b,c,d], [a,b,'_',d], or a multitude of other
>My current thinking leads me to believe that more complex
>pattern-matching based on queries like ['$1', '<', 200] will be too
>slow to handle the expected transaction rate. But I'd be happy to find
>out that I'm wrong.
>It would be wonderful to discover that such a thing already exists,
>such a thing as either the simple wildcard match or the more advanced
>pattern matching grammar that Erlang supports (as described in the erts
You may want to check out the ets:select() function.
It allows you to perform quite advanced pattern matching on ets tables,
using basically the same pattern matching language as for trace filters.
In OTP R9B, there is also the possibility to write match filters using
more traditional erlang syntax (it is then transformed into the match
syntax described in the erts manual.)
If ordering is important, ordered_set tables can be used. If your match
pattern avoids wild cards in the first part of the key, when matching on
an ordered_set table, the bound part of the key will be used to narrow
(I was going to provide a good example from the man page, but can't
access the documentation right now. Look at the man page for
More information about the erlang-questions