Akina

https://www.postgresql.org/docs/current/functions-...

Оператор конкатенации JSONB - ||

В более сложных случаях - jsonb_set(), jsonb_insert()... в общем, посмотри сам.

SELECT id AS servie_id,
       name AS servie_name,
       MAX(TO_TIMESTAMP(created_at))::DATE AS last_trans_date
FROM services
GROUP BY 1,2
HAVING last_trans_date <= CURRENT_DATE - INTERVAL '7 day'

SELECT *
FROM table
WHERE to_char(dob, 'MMDD') = '0216'

Использовать 2 копии таблицы. Одну для получения даты по заданному UUID, вторую для выборки записей.

SELECT t1.*
FROM table t1
JOIN table t2 ON t2.uuid = @uuid1 
             AND t1.createdAt > t2.createdAt
ORDER BY createdAt ASC LIMIT 100

Трата состоит из трех этапов. Чтение баланса пользователя, проверка хватает ли средств и собственно запись нового баланса.

Странный подход. Достаточно на таблицу наложить ограничение неотрицательности баланса и безусловно выполнять операцию. Если средств недостаточно, ограничение сработает, сервер не выполнит изменения данных и вернёт ошибку. Один запрос, и никаких проблем с параллельным исполнением при правильно выбранном уровне изоляции по умолчанию.

баланс юзера расчитывается на лету и не хранится в юзере. Расчитывсется на основе истории его пополнений/расходов.

В этом случае - триггер, который посчитает актуальный баланс, проверит условие, и при недостатке средств сгенерирует ошибку. Хотя я бы всё же задумался о хранении актуального баланса, хотя бы на некий момент времени (скажем, на полночь, чтобы доподсчитывать только по операциям текущего дня, а не по всей истории). Редкие ошибки в нём, даже если их не удастся избежать, обойдутся дешевле, чем система, способная каждый раз считать баланс на лету и разводить конфликты.

Если в многопоточном приложении произойдет так что два потока прочитают баланс, проверят хватает ли средств на покупку и этот этап пройдет успешно для обоих, то далее последуют две записи, которые загонят юзера в минус. Какие есть варианты защиты от двойной траты?

Как раз уровень изоляции. При правильно выбранном уровне хрен чего второй прочитает, пока первый не завершит свою транзакцию и не отпустит ресурсы.

Добавь в источник данных копию изменяемой таблицы, связанную по первичному ключу или иному уникальному полю/выражению, и оттуда возьми исходное значение.

DEMO

DISTINCT - это фактически частная форма GROUP BY. А потому к ней относятся все ограничения для GROUP BY в части использования полей источника данных в оконных функциях, выражениях пост-отбора и сортировки.

Посему используйте поле выходного набора для сортировки.

SELECT DISTINCT (regexp_split_to_array(commend, E'\\s+'))[:3] AS first_3_words
FROM orders 
ORDER BY first_3_words[2];

В голове идея создать varchar ячейку и в неё через запятую всё записывать.

С точки зрения работы с СУБД хранение массива данных в виде CSV-значения - крайне неудачный вариант. И весьма проблемный в обработке. Впрочем, если речь идёт о достаточно статичном массиве данных в сотню записей - вариант допустимый.

Нормализованная структура, удобная в обработке, может выглядеть, например, так (само собой, это только кусок для хранения слов и фраз):

CREATE TABLE words (
    word_id INT AUTO_INCREMENT PRIMARY KEY,
    word VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE phrase (
    phrase_id INT NOT NULL,
    FOREIGN KEY (phrase_id) REFERENCES phrases (phrase_id),
    word_id INT NOT NULL,
    FOREIGN KEY (word_id) REFERENCES words (word_id),
    word_position INT,
    PRIMARY KEY (phrase_id, word_position)
);

Ну так перемешай...

SELECT string_agg(concat(substring('ABCDEFGHIJKLMNOPQRSTUVWXYZ', ceil(random() * 26)::integer, 1),
                         substring('abcdefghijklmnopqrstuvwxyz', ceil(random() * 26)::integer, 1),
                         substring('0123456789', ceil(random() * 10)::integer, 1),
                         substring('!#$%&()*+,-./:;<=>?@[]^', ceil(random() * 23)::integer, 1)
                         ),
                  '' ORDER BY RANDOM()
                  ) 
FROM generate_series(1,8);

Используйте CTE - туда слона запихнуть можно, и, если надо, то и не одного, хоть скалярно, хоть набор записей...

Типа (игнорируя синтаксис, только принцип):

WITH
some_data AS ( SELECT ARRAY(1,2,3) AS some_value )
SELECT * 
FROM some_table
CROSS JOIN some_data
WHERE some_table.some_field NOT IN some_data.some_value

К тому же такое решение вполне себе переносимое.

Можно ли создать партишен ... куда бы попадали данные только за последние 365 дней

Нет, динамические границы раздела - такое в принципе невозможно.

В документации показаны примеры. Когда создается базовая таблица table_base и дальше от нее создаются партишены

Не лезьте в высокие материи, не зная основ. Начните с самого обычного RANGE PARTITIONING. Одна таблица - куча разделов, и никаких надтаблиц.