mnesia usage optimisation

Sean Hinde <>
Thu Jul 25 22:16:42 CEST 2002


I think the problem is that indexes are built using a linear search
mechanism when you have many items with the same value.

You could get around this by creating a new table wherever you wish to store
more than 1 destination node against a single source node - store the name
of the new table against your source node instead of the actual
destinations, and store all the destinations in the new table.

You would need to do this for both directions much like Ulf's suggestion. It
should be possible within a couple of reads to get whatever data you want..

I'd have a go at making it but I have a 2 hour drive ahead of me and it's
already 9-15pm (excuses, I know!)

You would run out of mnesia/ets tables eventually..


> -----Original Message-----
> From: Luke Gorrie [mailto:]
> Sent: 25 July 2002 18:59
> To: Ulf Wiger
> Cc: 
> Subject: Re: mnesia usage optimisation
> Ulf Wiger <> writes:
> > You could perhaps try using two ordered sets:
> Nearly works :-)
> In the start of the transaction, all operations are very fast, even if
> the table is already big. But as a large transaction proceeds, the
> 'match' operations get slower. It looks like it goes O(N)ish on the
> number of table updates. My access pattern is basically a chain of
> read-write-read-write..
> I'm guessing it's less efficient to match on the data structure for
> pre-committed values?
> Any other ideas?
> I'm probably overdoing my Mnesia usage really :-)
> Cheers,
> Luke

This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.

More information about the erlang-questions mailing list