<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Well, I've never written to this table before or after converting it to a fragmented table. When you say "this" can happen are you referring to the problem that Chandru said? That I've somehow ended up with records in the wrong fragment? <br><br>Sent from my iPhone</div><div><br>On Jul 6, 2013, at 5:17 AM, Evgeny M <<a href="mailto:donpedrothird@gmail.com">donpedrothird@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br>This may happen if you used dirty_write functions, even if you did this in activity with mnesia_frag callback<div><br>пятница, 5 июля 2013 г., 19:07:35 UTC+4 пользователь Noah Schwartz написал:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">I have a table of type set that worked fine as a non-fragmented table. We started seeing performance issues with the table and with the anticipation of more clients in the system, we were worried the size would exceed the 2 GB max. <div>
<br></div><div>The table contains chat messages and we purge records older than 7 days. There seem to be a number of keys that don't show up in a read activity but, do show up when doing a table dump, a select, or using qlc to find records. As such, when this purge policy runs records are found that when I try to delete don't actually get deleted. It almost seems like read/delete are working off of one set while qlc is working off of another set.</div>
<div><br></div><div><br></div></div>
</blockquote></div></div></blockquote></body></html>