WishesFire

Если отформатировать запрос, чтобы было видно, что происходит, получим следующее:

SELECT coalesce(A.id, :coalesce_1) AS card_id, 
       coalesce(A.serial_number, :coalesce_2) AS card_number, 
       coalesce(B.name, :coalesce_3) AS prj_name, 
       coalesce(C.name, :coalesce_4) AS client_name, 
       coalesce(A.user_name, :coalesce_5) AS card_owner_name, 
       coalesce(A.user_phone_number, :coalesce_6) AS card_owner_phone_number, 
       coalesce(A.balance_current, :coalesce_7) AS current_balance, 
       coalesce(A.balance_bonus, :coalesce_8) AS bonus_balance, 
       coalesce(A.active, :coalesce_9) AS card_status, 
       coalesce(D.name, :coalesce_10) AS tariff_plan_name, 
       NULL AS anon_1 
FROM cashless_card 
JOIN company ON cashless_card.company_id = company.id 
JOIN voc ON cashless_card.voc_id = voc.id 
LEFT OUTER JOIN tariff_plan ON cashless_card.tariff_plan = tariff_plan.id 
WHERE cashless_card.company_id IN (__[POSTCOMPILE_company_id_1])

Почти очевидно, что в таблицах company, voc и tariff_plan поле по имени id - это первичный ключ... но хотелось бы подтверждения.

Впрочем, видно, что для оптимизации запроса в таблице cashless_card крайне желательно наличие индекса (company_id). Следует также проверить эффективность индекса (company_id, voc_id, tariff_plan), и аналогичного с переставленными местами последними 2 полями (первым ставить то, которое более селективно).

Кроме того, эффективность запроса сильно зависит от количества идентификаторов в списке, который передаётся в условие WHERE cashless_card.company_id IN (__[POSTCOMPILE_company_id_1]). Если их более десятка, есть смысл преобразовать этот список в набор данных (синтетическая UNION-таблица) и использовать как ещё один источник данных запроса.

Ну и надо понимать, что наличие LIMIT/OFFSET только замедляет выполнение запроса. Причём чем больше OFFSET, тем сильнее это замедление.