I had a look at the Reports list (which as of today is rendering, albeit very slowly) and the immediate problem I see is that you have 5 join elements, some to quite large tables, none of which use the 'id' as the value - they all use the (non unique) label as the value (like 'customer_name'). That's going to cause terrible problems, for both speed and functionality. You REALLY need to redesign that, and use the PK of the joined table (usually 'id') as the value. That's why we put "(recommended)" next to it in the selection.
This isn't a Fabrik thing, it's a database thing. WHen joining rows in a relational database, you do it from FK (foreign key) to PK (Primary Key). Here's why ...
SELECT * FROM parent LEFT JOIN child ON child.parent_id = parent.id
... joins just that one record ... the child table has an FK which is the single, unique, indexed PK id of the parent.
Whereas ...
SELECT * FROM parent LEFT JOIN child ON child.name = parent.name
... trying to join them on a 'name' ... if you have two "John Smith" in the child table ... there is no way of knowing which one should be joined. And that select will get both.
Then when you do half a dozen joins like that, and any of them wind up with duplicated selections because of non-unique keys, you exponentially increase the number of rows being selected. A simple display of 10 rows can wind up trying to sort through tens of thousands of selected rows to find the distinct ones.
It won't be trivial to change, as you'll have to manually alter you existing table data to change it from label values to FK values. But this problem is just going to get worse and worse as your tables grow.
-- hugh