Recommendation feed is unbearably slow.

[leonardr]

The recommendation feed gets a bunch of identifiers and then builds a feed out of works equivalent to those identifiers. It uses the fn_recursive_equivalents function on Identifier.id to do that.

The problem is that when you join that against mv_works_for_lanes, the restriction on Identifier.id isn't used to eliminate rows from mv_works_for_lanes based on its identifier_id. This causes a full table scan of the materialized view, which is bad enough to bring down the site if a lot of people are using it.

We've run into something similar for work id and license pool id, and the solution was to add a clause to apply the restriction twice, once on the materialized view and once on the table that was the source for that data.

It's also possible the answer is to use the restricted Identifier.id in the join against the materialized view, rather than to apply the same restriction twice.