Melkij

В том смысле чтобы participants.contest проверял, что такой uuid есть в users.guid или teams.guid?
Нет, так нельзя.

Сделайте триггер который будет копировать логику FK.
Вынесите общие поля в отдельную таблицу, объединяйте как 1:1 с teams или users
Вынесите общие поля в отдельную таблицу, воспользуйтесь наследованием таблиц (inherits).

Такого процесса либо утилиты в postgresql нет. Особенно в PGDATA (aka data_directory) если словосочетанием "в папке PostgreSQL" вы подразумевали PGDATA.

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

select distinct on (raw_id) raw_id, id, single_sum 
from tablename
order by raw_id, id desc

Может быть как обычно перепутал направление сортировки.

Это functional dependency. Если планировщик сможет свести ваши подзапросы или cte к уникальному индексу - functional dependency позволит ограничиться указанием только полей этого уникального индекса.

Встречный вопрос: а зачем вам такая группировка вообще? Для приведённых запросов бесполезна и лишь вредна.

Проверьте сколько запросов делает непосредственно браузер.

Например, фавиконка.

ON DUPLICATE KEY UPDATE. Сверяйте по буквам.

А если делаю ON DUBLICATE KEY UPDATE `pipeline_name` = '$pipelinename' ,
то записи дублируются

Удивительно. Верится слабо.

Никакого парадокса, задокументированное поведение. Скопирую недавний ответ отсюда:

Потому что вообще не надо сравнивать строки и числа. Если поле строковое - сравнивайте только со строкой. Хоть при этом происходит и вполне задокументированное поведение.

Расходники.
Не имеет значения.

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

Никакой. Это расходники. Все накопители - расходники. То что накопитель даёт прочитать то что ранее записали - не более чем случайность. Не будете вдруг терять данные только если примете эту мысль. Для важных данных 3 и более копий по разным накопителям - норма. В том числе географически разнесённые.

На горизонте сохранения данных в десятилетия задача решения не имеет вовсе. Да, это проблема современного мира.

1й более ударнопрочный

Не бывает ударопрочных HDD. Чисто по физическому устройству этого класса накопителей.

Это вам как администратору должно быть виднее, зачем вам отдельный /home в 5гб и прочие фрагменты, нужны ли они и какого именно нужны размера.

А так чаще на гипервизорах /boot на отдельном разделе raid1, всё же остальное полезное собирается в lvm поверх рейдов (и виртуалкам целиком LV монопольно, а не файлики в ФС). Возможно в разные VG.

pgbouncer не имеет отношения к балансировке нагрузки. Вообще. Это pooler. В норме в transaction mode.

Типично pgbouncer ставится на тех же хостах что и база, каждый смотрит только в свою локальную базу. Балансировка по баунсерам равнозначных реплик - что-то вроде haproxy или приложением.

sudo - запуск команды от имени пользователя ОС.
Пользователь ОС не имеет совсем ничего общего с пользователем в БД. Пользователя ОС вы не создали, ответ sudo закономерен.

Для использования psql sudo не нужен. Нужны настройки pg_hba.conf и сам psql. Например, psql -U user1 database1

Нужно получить диапазоны цен, где максимальная цена больше определенного числа.

Мне кажется вам нужен вовсе:

select product_id, min(price), max(price) from prices group by product_id having max(price)>= ?

А отвечая на вопрос в лоб - lateral join'ом перенести подзапрос в секцию from и всё.

Если база большая - pg_upgrade в link mode. В документации шаги вполне описаны. Желательно иметь реплику на всякий случай.
Если база маленькая - pg_dumpall и импортировать в новую версию из дампа. Собственно всё просто: запустить новую базу на отдельном порту, снять дамп, залить дамп, остановить старую базу,, перезапустить новую на нужном порту.

Просто запустить бинарники одной major версии на datadir другой major версии - не получится.

Для обновления в пределах одного сервера нужны бинарники обеих версий СУБД. Инструкцию по установке уже расписал Alexey Dmitriev

не ниже 10.1(на локалке у меня 10.1) или лучше ставить последнюю 12?

10.11 минимум. Нечего тестировать давно закрытые ошибки.