Sorry to reply to my own post.
TL;DR Is there pagination? Then a smaller set may return much faster.
I was thinking over my reply and may have forgotten a fundamental
aspect … If you say 2200 categories, 8000 products.
How many entries does you query return ?
(replace .add with .count at the end).
How many do you need ?
What happens when you add .limit(20) to your query ?
By which “primary object” do you want to sort and paginate ?
(I will assume ‘Product’ in the discussion below).
With the includes that are currently implemented, you may
have to redo the whole query into 2 qeuries …
- for fetching the “primary objects”
(e.g. exactly 20 Products, no additional “has_many” data, because
that would increase the number of returned rows for 1 product and
make proper pagination in the database impossible; including
“belongs_to” here is no problem)
- a second query for fetching eventual “has_many” data
on those 20 “primary products” (is that “Reification” ?)
If the performance problem could be solved by taking the
pagination into account, that would be a much better
solution that building cache columns in this early phase
of your project.