Thank you again Cristian,<br><br>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 .<br><br>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.
<br><br>going through all these records to select what we want is not efficient and very slow.<br>thats why I thought about indexing (but there is no support for that in dets) <br><br>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.
<br><br>Can we  speeds  up the  retrieving   by changing this N .<br><br>Changing the database to another type is not very easy at this stage as it need a huge change in the coding.<br><br>thanx.<br>chamila<br><br><div><span class="gmail_quote">
On 12/21/06, <b class="gmail_sendername">Christian S</b> <<a href="mailto:chsu79@gmail.com">chsu79@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 12/21/06, chamila piyasena <<a href="mailto:tchamila@gmail.com">tchamila@gmail.com</a>> wrote:<br>> actually i was trying to improve the performance(the data retrieving ) of a<br>> smsc log server.<br>><br>
>  the coding that I have  use dets:select(Name, matchspec, N) inside the<br>> function that gives the out put according to the request.<br>><br>> And there may be huge number of rows(may be millions) that keeps track of
<br>> sms records.<br><br>Why are you calling select on this data? Are you trying to find<br>messages destined for a given terminal? Are you searching messages<br>that are undelivered and too old so you can remove them?
<br><br>All these things warrant extra indecies by you. If you have millions<br>of messages you probably want the robustness from using mnesia in a<br>distributed setting too. Downtime affects too many users.<br><br>When you receive a message, besides storing its content, also keep
<br>another table up to date that maps a terminal id to the messages<br>destined for it.<br><br><br>Using an external SQL database could be an alternative.<br></blockquote></div><br>