How big is the overhead of a Mnesia table?

I’m building an application in which at some point in the near future we’d like to use the distributed features of Mnesia. However, since this is a chat application and there is little use for e.g. cross-channel searching capabilities, I’ve been thinking about the best structure for the tables.

It might make sense to create a table per channel, since common search-operations only happen in one channel, (so then we do not have to filter 99% of the messages because they are not of interest since they are from another channel right away).

In a more general sense: if you have structured data, fields that (together) uniquely identify groups of data that do not often need to be considered together, might be used as (part of the) table name instead, right?

However: Creating a new Mnesia table might itself have some overhead. How large is this? When does it make sense to split tables into more, smaller ones?

Mnesia is just some wrappers around some ETS tables and I think a GenServer, so it is ETS and a GenServer.

So that basically means: Very small, right? :slight_smile:

As long as it is remembered that the system only supports a few thousand ETS tables (configurable via a command line argument as I recall?). :slight_smile:

But yes, very small. ^.^

Even the mnesia calls just delegate to the ets calls for in-memory tables, it’s that simple. :slight_smile:

ERL_MAX_ETS_TABLES. This limit can easily be reached when using mnesia. I think mnesia uses temporary ets tables as well so it is not just about static tables.

I don’t think there are any considerable drawbacks to increase this by quite a margin.

iex(1)> :erlang.system_info(:ets_limit)
2053
1 Like