спасибо)

Коллеги, а здесь по pgbadger вопросы можно?
Проапдейтили с 1.9 до 1.14 (знаю, что есть уже 1.15, но с ним то же самое), теперь в секции про медленные запросы массово такая фигня:
6h21m1s | duration: 125.424 ms rows: 1 size: 5092 bytes SELECT * FROM ...
Причем некоторые нормально:
17m23s | SELECT DISTINCT ...  
а некоторые так. В настройках логирования ничего не менялось. Куда копать?

Кто-нибудь может подсказать, как правильно пользоваться оператором ~~ jsquery?

Оператор фильтра: ~~. Принимая данные jsonb в качестве левого операнда и выражение jsquery в качестве правого, этот оператор ищет в данных jsonb элементы, удовлетворяющие условию, заданному в выражении jsquery, и возвращает массив таких элементов, если они находятся

В частности, могу ли я, к примеру, получить c помощью только него массив id из массива элементов, где is_active:

’[{id: 1, is_active: true}, {id:2, is_active:false}, {id:3, is_active:false}]’::jsonb

?

Коллеги, а DROP COLUMN на 9.6 будет переписывать всю таблицу или быстро выполнится?

посмотрите Changelog на предмет новшеств, может что-то поменялось

Добрый день, коллеги.
В словах могу путаться, так как новичок, не бейте палками 😂

Делаю структуру БД для микросервиса технической поддержки.
Можете, пожалуйста, посмотреть - правильно ли сделал.

У текущей реализации есть некоторые проблемы
1. Вносить данные нужно с помощью транзакций, так как при создании тикета на сайте мне нужно заполнить несколько таблиц - создать тикет, создать сообщение в тикете, обновить статус тикета, назначить менеджера на тикет. Если хотя бы одно из этих действий в бд не прошло - от остальных толку нет.
2. При выводе пользователю его тикетов вместе со статусом и прочими данным в запосе будет слишком много JOIN'ов.

Правильно / логично составлена схема?
Что можно перестроить, чтобы сократить кол-во JOIN'ов?

Если вы знаете готовые варианты схем для технической поддержки - поделитесь, пожалуйста.

быстро

Спасибо

А почему бы не хранить заполнении тикета в Redis, а в psql сохранять уже готовый тикет?

Что вы имеете ввиду под "заполнении тикета в Redis"?

Пользователь вводит первое поле - клиентская апка срочно бежит сохранять это дело в редис. Сущностью анкеты в пг это пока не является. Кэш, всего лишь временный кэш, незаполненная инпрогресс тикета. Хранить часов 150 и хорош.
Клиент прервался - вышел. Зашел снова - спрашиваем данные из хранилища. Нету - идем в поисках инпрогресс анкеты в редис.
находим - вываливаем данные в апку. Пользователь продолжает заполнение.
Закончил заполнение анкеты? Отправляем все на сервер, который сохраняет уже в psql. Меньше сущностей, связей и тд

Теперь понял, спасибо.

Я у себя в примере не рассматриваю незаполненные тикеты.

Пример - создание тикета.
При создании тикета пользователь должен указать первое сообщение и приложить файлы.
Предположим, что всё успешно и валидно.

Что теперь нужно сделать:
1. создать запись в таблице ticket
2. создать запись в таблице ticket_message
3. создать запись в таблице ticket_message_attachmet
4. создать запись в таблице ticket_ticket_status
5. создать запись в таблице ticket_manager

все действия внутри транзакции

зачем в редис? можно же просто в localStorage браузера когда все поля заполнены, тогда уже в сеть идти (редис/бд там или апи бэкенда)

Мб клиент не браузер)

в локальный файл тогда... просто это оверхед на каждый чих ходить в сеть

Приветствую.
Как я могу использовать функцию overlaps
чтобы один период сравнить с результатом запроса?
Например:
(coalesce(cre.validity_from, '2019-01-01'), coalesce(cre.validity_to, '2030-12-31'))
overlaps
(select
 min(coalesce(d1_cre.validity_from, '2019-01-01')) as from_,
 max(coalesce(d2_cre.validity_to, '2030-12-31')) as to_
from
 contragent_real_estate d1_cre
where
 d1_cre.real_estate_id = re.id)

Спасибо)

1) Как часто вы хотите менять систему рейтингов и статусов? Я как-то сомневаюсь, что вы будете редактировать ticket_status, mime_type и ticket_rating через админку чаще, чем раз в год - два.
2) Почему вам нужно прямо сразу кого-то назначить на задачу? Ситуация "все операторы заняты" всё же вполне реальна.
3) Не вижу поля "вот сейчас вашей задачей занимается Петя" )

Лишние соединения можно срезать уже на стороне приложения. Например, можно пройтись по выбранным из базы сообщениям и сделать SELECT * FROM ticket_message_attachment WHERE ticket_message_id IN (<список сообщений на экране>).
ticket_status, mime_type и ticket_rating включать их в JOIN смысла нет - таблицы из < 100 записей лучше целиком в память утащить один раз и использовать где надо.

Спасибо за ответ))

1. Да, редко. Скорее всего только в самом начале.
2. Не обязательно, чтобы одному менеджеру был назначен один тикет. Можно назначить сколько угодно - для этого я и сделал промежуточную таблицу. А метка времени там для того, чтобы переназначать менеджеров на тикеты. То есть сейчас занимается тикетом тот у кого самая последняя метка времени.
3. Я думал это сделать через JOIN к таблице ticket_manager

Если честно - не очень пронял про лишние соединения. Можете, пожалуйста, уточнить.

Про таблицы из < 100 записей понял, спасибо. Так и сделаю.

По лишним соединениям - иногда несколько независимых SELECT будут быстрее JOIN. Например, как вы себе представляете самую жирную цепочку JOIN'ов?