mnesia:match_object() on an ordered_set
Ulf Wiger
etxuwig@REDACTED
Fri Apr 25 13:52:00 CEST 2003
On Fri, 25 Apr 2003, Hakan Mattsson wrote:
>Uffe> As to preserving a global order, mnesia_frag in its default
>Uffe> implementation makes this hard. On the other hand, what's
>Uffe> the point of having multiple ordered set fragments if
>Uffe> objects are distributed among the fragments using a hashing
>Uffe> algorithm? (: Each ordered_set fragment will contain only
>Uffe> a pseudo-random subset of the global set, so it's doubtful
>Uffe> whether there is any point to the local ordering anyway.
>
>In most cases it would not be any point. But if you have an
>access pattern with frequent matching of a partitially
>bound key, it could make a big difference. You would in the
>standard case (using the default hash function) still need
>to perform the match in all fragments, but ets would not
>need to perform an exhaustive search of the entire table.
Good point.
>If the documented behavior of mnesia:match_object/2 on an
>ordered_set, is changed to also guarantee an ordered
>result, then this implies that this is consequently
>implemented. The semantics should be the same for both
>ordinary tables and fragmented tables and not rely on any
>customized fragmentation scheme.
Considering that my suggested change basically doubles the
performance of the merge of the found set and the
transaction store, given an ordered_set, one might want to
implement it anyway, without documenting it as a guarantee.
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
More information about the erlang-questions
mailing list