Fragmented tables in Mnesia

Ulf Wiger etxuwig@REDACTED
Thu Jul 10 00:12:52 CEST 2003


On Wed, 9 Jul 2003, Erlang Questions wrote:

>Hi, everyone.
>
>Does someone know if it implies lose of performance using
>mnesia:activity to execute reads and writes in a fragmented
>table?

There is an overhead of one ets:lookup() per read or write
operation when you use the mnesia_frag callback for
non-fragmented tables. This should be regarded as
negligible.


>My question goes to indiscriminately use mnesia:activity
>even in those cases where the table is not fragmanted
>(yet). This way, the final user could make its own
>fragmentations whenever he wants without having to change
>any code line. It will be a good option if there is no
>significative overhead in using such function.

You could also make sure that you always use your own
function, myDbLib:activity(Kind, Fun), which could start by
calling mnesia:activity(Kind, Fun), and later perhaps call
mnesia:activity(Kind, Fun, mnesia_frag).

>Or maybe there is some other way to prevent code of
>writting or reading from a table that could be fragmented
>in the future. I am new in the "Mnesia Table Fragmenters
>Club" and my experience is based on the examples found in
>the documentation.

I would not recommend that. My recommentation is to use your
own wrapper to mnesia:activity() right from the start. It
gives you the most flexibility and "no" overhead. To
reiterate, the overhead when using mnesia_frag for
non-fragmented tables is minimal, but there is no reason to
lock yourself into forever using the mnesia_frag callback
either. There are other custom callback modules, e.g. rdbms,
and your future requirements may cause you to outgrow
mnesia_frag as well. You may even end up wanting to write
your own callback module (it's not that difficult). The
trick then is not to have mnesia_frag hard-coded in 4711
different places.

/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