Re: mnesia:match_object() on an ordered_set

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