[erlang-questions] Optimal way to restrict a ram_copies table to N entries

[Scott Lystig Fritchie]

>>>>> "jr" == Joel Reymont <joelr1@REDACTED> writes:

jr> The size of the table can be found out with mnesia:table_info/2 [...]

Try timing that call on a table with 100 vs. 1 million items in the
table, just to be certain.  :-)

Here's an example of a 112K entry ordered_set table.  NOTE: I'm using
ets:info/2, not mnesia:table_info/2, though it shouldn't make a
difference (in theory) ... I don't have a "real" Mnesia table lying
around in the lab with 100K or 1M entries in it.

  (test1@REDACTED)10> timer:tc(ets, info, [test_1_cache, size]).
  {5,112259}

... {looks at R11B-5 source code} ...  Hrm, the AVL implementation
keeps track of the # of items in the tree in blah->common.nitems, so
mnesia:table_info(Tab, size) should be a O(1) operation.  5usec for
the above operation suggests to me that it isn't behaving like O(N),
my hardware isn't quite that fast.

jr> and if erlang:now() is
jr> used as a timestamp then the beginning or the end of the queue can
jr> be found with mnesia:first or mnesia:last.

A tuple of {now(), make_ref()} would work around any
alleged-phantom-erlang:now()-duplicate-bug(*), if you're paranoid.
It'll take a few extra words of memory per table entry, but that's
nothing for a paranoid person to worry about.

jr> I think the first item inserted can be found out with mnesia:first
jr> even on a set table.

I don't think so.  I think you'll get the first item in the first hash
bucket/slot, which almost certainly isn't what you're looking for.

-Scott

(*) Unless you're also truly paranoid, in which case you will suspect
that make_ref() will also give you duplicates.  That's pretty far on
the paranoid end of the spectrum, since belief in focused cosmic rays
disrupting your RAM is may be nearby on the same spectrum.