Николаха,

Курить LIMIT вместо FETCH ...
LATERAL вместо table()
и взять LEFT JOIN LATERAL () ON TRUE

Николахаvyegorov,

Тоже вариант! ))))

А какой запрос будет менее ресурсо затратным для сервера, если кол-во записей в таблице клиентов перевалит за 50 000, а таблица платежей, при условии что база ведется с начала тек года, 50 000*12 мес !?
эти объёмы можно сгенерировать руками за 5 минут на тестовом сервере
заодно и выкурить explayn analyze
не забыть об индексах -- без них -- всё несколько иначе (без индексов выиграет скорее всего distinct on или вообще какая-нть аналитика)

ON -- это ON сабкляуза кляузы join
left там для неплательщиков



по секрету скажу, что будь distinct on в планере реализован по человечьи -- он не отличался бы (в случае большого числа правильно проиндексированных платежей) планом от lateral . но оптимайзер пж тут пока не запинали (и вообще отсутствие миллионов индусов не на пользу планеру), зато синтаксис позволяет это все руками

PS
при всего по 10-12 платежей в одно рыло -- полный скан по платежам с unique после хеш-джойна и сорта [т.е. distinct on] скорее таки выиграет. тут варианты. но будет тоже не быстрым.