chamila piyasena tchamila@REDACTED
Thu Dec 21 12:17:33 CET 2006

Thank you again Cristian,

actually it only stores the CDR records of the SMS(from number, to number ,
delivered or not, date,  etc.. ) not the SMS it self and a separate dets
file is created every hour .

If some one want to see records  related to a particular phone number in a
given period,  suppose  in  a duration of month  there will be many rows in
corresponding files.

going through all these records to select what we want is not efficient and
very slow.
thats why I thought about indexing (but there is no support for that in

and I changed the value N  in the select  function to a small value(actually
from 50000 to 2000) it speeds up some requests I made in the application.

Can we  speeds  up the  retrieving  by changing this N .

Changing the database to another type is not very easy at this stage as it
need a huge change in the coding.


On 12/21/06, Christian S <chsu79@REDACTED> wrote:
> On 12/21/06, chamila piyasena <tchamila@REDACTED> wrote:
> > actually i was trying to improve the performance(the data retrieving )
> of a
> > smsc log server.
> >
> >  the coding that I have  use dets:select(Name, matchspec, N) inside the
> > function that gives the out put according to the request.
> >
> > And there may be huge number of rows(may be millions) that keeps track
> of
> > sms records.
> Why are you calling select on this data? Are you trying to find
> messages destined for a given terminal? Are you searching messages
> that are undelivered and too old so you can remove them?
> All these things warrant extra indecies by you. If you have millions
> of messages you probably want the robustness from using mnesia in a
> distributed setting too. Downtime affects too many users.
> When you receive a message, besides storing its content, also keep
> another table up to date that maps a terminal id to the messages
> destined for it.
> Using an external SQL database could be an alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20061221/ca51535b/attachment.htm>

More information about the erlang-questions mailing list