нет, типа не пройдя весь запись 2раза сразу вывести в 1 результат

типа там будет
group (name), group (type), sum(amount)
но не понимаю как написать запрос

Комбинаторно пройтись по именам/типам и вывести сумму для каждой уникальной пары name-type

Тоесть у тебя и name во многих случаях одинаковые?

да

все решил
просто надо было

group by name, type

вместо

group by name
group by type

Вечер, господа.
Подскажите, есть свойство сущности, значения которой ограничены количеством (в моем случае - 4). Есть 2 варианта хранения - в отдельной таблице или в основной. Во втором случае можно или 4мя колонками или массивом в одной. Вот в случае если - массивом - как прстроить индекс так, что можно было искать по элементу в массиве. Тип данных - строка.

не храни ничего в массивах просто))

Обычный GIN-индекс. Но лучше так не хранить, в большинстве случаев.

можно хранить, если заведомо знаешь, что не будет много данных в массиве, что бы таблица не затоастилась

Если хранить в 4х колонках, то запросы становятся тяжелыми, а если в отдельной таблице, то как написать констреин на количество?

При чём тут много или мало данных?
Это сравнение гнилых яблок с апельсинами, извините (я намекаю на консистентность, если что). ;)

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

Причем тут сравнение яблок и апельсинов? Тип один. Что там лежит - понятно.

коллеги,всех приветствую!
У меня есть таблица USer, которая состоит из двух столбцов
id_user name_user
1              Vova
2              Vania
3              Dasha
4              Katya
5              Sasha
.......................

У меня стоит задача соединить двух пользователей. Если я верно понял,для этого надо создать вторую таблицу связей:
id_user_1   id_user_2
1                     2
1                     3
3                     5
............................
Вопрос - это верный подход или связи нужно создавать по другому? Если да, то нужно ли дублировать эти связи (т.е. 1-2 и 2-1)?

> Если хранить в 4х колонках, то запросы становятся тяжелыми

Смотря какие... но такая структура — тоже неправильная (ненормализованная), скорее всего.

> то как написать констреин на количество

Триггером, скорее всего.

> Причем тут сравнение яблок и апельсинов? Тип один. Что там лежит - понятно.

Вам понятно, а я не знаю, что Вы храните.
А "в общем" такие вещи бывают ограничены FK или constraints, например. И в случае массивов это всего (по умолчанию / простыми способами) просто нет — "гнилые яблоки". ;)

Если коротко, через BTREE такой индекс не построить? (Я про вариант с массивом)

Да, тут нужен GIN.
Причина в том, что btree, какие преобразования ни делай, это одно значение "на входе" — одно индексируемое "на выходе".
А Вам нужно, чтобы из одного значения-массива получалось несколько ключей — это GIN.

А с GIN'ом у нас проблем никаких нету? Просто раньше вроде-бы были...

Как будто с b-tree не было. ;) Баги всегда возможны, ясно дело.