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

ну, а предложенный первый вариант? одно поле, айдишники не пересекаются, приложение определяет чей айдишник

ну так...

всё равно не так. Ссылочную целостность придеца делать триггерами

все запросы - надо будет писать с джойном обоих таблиц

странновато карочи

Эти "внешние системы" разве не должны работать от имени какого-то пользователя?

в данном случае они от своего имени работают

Я бы тогда два столбца сделал.

IS NULL, очевидно. ;)

Как-то можно посмотреть explain запроса с placeholder-ами, не подставляя туда конкретные значения?

Блин, кажется ответ очевиден.
Ладно, всем спасибо)

я проблематику, видимо, не до конца объяснил)

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

Сейчас человек может написать поисковую строчку, которую код раскидает на токены-слова-условия, и айлайком пройдется по полям в зависимости от их типа.
Вот как раз enum’а не хватало, with cte прекрасно справился со своей задачей без лишнего усложнения кода

P.S. для поиска автоматически генерируются километровые SQL запросы и PostgreSQL их прекрасно жрет и очень быстро ищет

Здравствуйте. Подскажите, пожалуйста, как остортировать результат по name. Документация не помогает, у меня нет понимания почему такая конструкция не может работать:

SELECT name, COUNT(*), array_agg(name ORDER BY name)
    INTO _name, _count_files, _file_names
    FROM files
    WHERE dir_id=file_dir_id AND name ILIKE file_name||'%'
    ORDER BY name;

SELECT name, COUNT(*), array_agg(name ORDER BY name)
    INTO _name, _count_files, _file_names
    FROM files
    WHERE dir_id=file_dir_id AND name ILIKE file_name||'%'
    ORDER BY name;

Вы хотите положить результат в отдельную таблицу, поэтому делаете select into?

Upd.
Если да, то после into нужно оставить имя таблицы.
Если нет, то нужно убрать into и всё, что правее?

Приветствую всех!👐
Знающие люди подскажите пожалуйста.
Есть клиент у которого в самом начале рабочего дня,
когда люди начинают использовать сервис (nginx - php-fpm - postgresql - redis(отдельный сервер))
Сервер уходит в 100% CPU, сервис начинает тупить, потом в течении дня нагрузка снижается.
В основном видно что загрузка вызвана процессами PostgreSQL.
Пробовали использовать файловый кэш для приложения, пробовали поднимать лимиты в redis, но нагрузка по CPU не уходит. Пробовали мониторить запросы консольной утилитой, но ничего не увидели, к сожалению DBA у нас нет.
Будем увеличивать количество ядер CPU, но это борьба со следствием,а не причиной.
Встал вопрос мониторинга метрик и вот хочется понять из вашего опыта, что лучше для этих целей использовать, чтобы было можно снять метрики с PostgreSQL и Redis и
понять в чем дело или хотя бы понять направление в котором копать. 🧐

не используйте SELECT INTO для создания таблиц, стандартный синтаксис CREATE TABLE AS SELECT …
SELECT INTO выпилили для 14-й версии

Лучше, конечно, дождаться ответов DBA, но я попробую помочь.

Возможно вы отправляете слишком часто запросы в PG.
Посмотрите в pg_stat_statements.

мониторинг на основе pg_stat_statements, хотя бы https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

Это plpgsql, мне нужны эти поля для обработки одинаковых имен.