Это данные о том, что значение с этим id уже суммировалось.
В агрегатной функции.
https://pastebin.com/FrTgkiA2

И, кстати, схема разнообразно "прекрасна".
К примеру:

    actual  timestamp(0) default now()       not null

Это две ошибки из https://wiki.postgresql.org/wiki/Don%27t_Do_This#Date.2FTime_storage в одной строке. Это успех, я считаю.

    actual  timestamp(0) default now()       not null

Вы имеете ввиду что нет таймзон? Так уж повелось с давних пор, совершенно не мешает, переделать, конечно, надо, но постоянно нет времени на это.

» Это две ошибки из
1. Да, используется не timestamptz. "Совершенно не мешает" — это "пока везёт" (или "никто не замечает ошибок" / "и так сойдёт"). ;)
2. Don't use a precision specification, especially not 0, for timestamp columns or casts to timestamp.

А где про второй пункт можно прочитать?
Такого не встречал но интересно почему нельзя.

Так уж случилось, что хранится так. Все связанные потенциальные проблемы известны и решаются на уровне бекенда. Я знаю о том, что на таймзонах можно сделать красивее. Когда нибудь мы обязательно найдем время и сделаеим это. Но сейчас вопрос не в этом.

Я ссылку просто так давал, Вы считаете? ;)
И, по-хорошему, всю эту статью стоит внимательно прочитать.

Читал давно, видимо упустил этот момент.

    actual  timestamp(0) default now()       not null

Хм, интересно.

Сейчас вопрос в том, что Вы не показали standalone test case.
Почему Вы тогда удивляетесь, что Вам не дают конкретных советов?
Воспроизвести у себя никто ничего не может, остаётся только гадать и "махать руками". ;)

Очень сложно сделать тест-кейс копированием существующей структуры. Одна таблица тянет за собой другую, не относящуюся к данной проблеме, и пошло-поехало.
Надо или написать изолированный тест-кейс или описать абстрактную проблему.
Вот, соображаю, что сделать быстрее...

Да Вы могли бы просто Foreign Keys "наружу" из этого подмножества таблиц порезать, а все нужные типы/функции и т.п. — добавить.
Да и обзорное описание того, что должен делать запрос / функция, тоже неплохо бы привести — так легче разбираться, IMHO.

Сейчас попробую текстом.

сходу что взгляд режет, постоянно идут преобразования в jsonb и обратно, зачем, вы глушите пг на неэффективное выполнение БЕЗ индексов.
хотите агрегировать, паковать в json пожалуйста, но делайте это только в верхнем слое запросов.
по хорошему, чтобы разобраться можно было бы сделать cte разделить на осмысленные блоки и неплохо бы
после нескольких часов обсуждения все таки указать версию пг.

то есть это такая как бы самодельная реализация дистинкта? запоминать все айдишники чтобы не дублировались?

Именно так.

Как-то так.
Есть следующие таблицы

client - данные клиента.

sale - содержит информацию о продажах ссылается на client.
sale_item содержит информацию об “элементе продажи”, ссылается на продукт, на продажу, содержит данные о количестве, о единице измерения, о цене продажи. Цена продажи - оьъект jsonb, содержащий value и код валюты.

product- содержит инфо о товаре.
catalog - описание каталога, каталогов может быть много.
catalog_category - описание категории, ссылается на каталог, также ссылается на catalog_category с образованием иерархической структуры.
product_category_mapping - маппинг продуктов на категории. Один продукт может принадлежать нескольким категориям или не пригадлежать ни одной.

Задача:
Сделать запрос, выдающий отсет по продажам за временной период  
⁃  суммарные показатели (сумма в разных валютах, количество в разных единицах, число продуктов, число категорий, число каталогов, число торговых дней, число клиентов)
⁃ то же самое в разрезе: По дням, по продуктам, по каталогам, по категориям, по клиентам.
⁃ в пункте выше также по каждому разрезу нужны массивы id продуктов, клиентов, категорий и т.д.

Мы индексы не глушим. О каком именно случае Вы говорите/

а нахрена так делать, если можно сначала выбрать уникальные, а потом по ним сделать агрегацию?

я это со вчерашнего дня понять не могу.