OK, I had a look at your site.
I think you may simply be hitting a limit we didn't anticipate when we started. If your list is grouped, then the calculations are grouped, so we can show the values for each group in your list. And rather than re-calculate everything on the fly every time you display the list, we only calculate when anything is changed (like submitting a form, saving changes to lists or elements on the back end, etc), and we store the values in that "serialized" attribute in the params field for the element.
So of course, the size of that serialized value grows, as your table grows, and the number of groupings increases. If you have a small list, grouped on (say) "name", and you only have three different names ... we only have to store 3 calculation values. But by the time you have tens of thousands of rows with hundreds or thousands of different names .... we have to store hundreds or thousands of grouped calculation values.
I think the only solution is to change the type of the 'params' field in our fabrik_elements table from TEXT to MEDIUMTEXT. This won't increase the size of the table, it just allows that field to grow much bigger.
So ... what I suggest is that you do a full database backup, then in phpMyAdmin we change the type of your params field. And I'll whip up the SQL update script we'll need in our next release build to change that type for all users, when they next update Fabrik.
Re:
However, I noticed sometimes at the bottom of the page list a huge display of IDs and sums.
That should only happen if you have a "split" on your calculation, as splits are another case in which we have to store multiple calculations in the serialized data.
-- hugh