Алексей Сундуков

Если не ошибаюсь в этом видео https://www.youtube.com/watch?v=HjLnY0aPQZo говорили о том, что не нужно использовать PgQ в наши дни.

Посмотрите в сторону NOTIFY/LISTEN: https://postgrespro.ru/docs/postgrespro/10/sql-notify

Использую обе РСУБД. Предпочитаю Postgresql, хотя конечно начинал с MySQL. Из того, что на практике приводит к такому предпочтению:
1) Отсутствие проблем на по сути пустом месте. Из последнего было, в одной базе есть таблицы с большим количеством текстовых полей. При вставке в одно из них чуть меньше 200 символов он отказывался ссылаясь на то, что переводите на динамические. И я значит должен начать курить тему движков мускула и выяснять, что мне оказывается нужна Barracuda. При той же InnoDb. Хочется спросить такого черта.
Или вот еще вспомнил. При попытке записи в поле данных, больше чем это возможно для данной колонки он делает запись тупо обрезав лишнее. И проблему могут не заметить очень долго вплоть до момента когда подниматься из бэкапа поздно, там все уже битое.
Или вот взять и сменить могут дефолтные значение переменных в рамках минорной версии. База после накатки апдейтов и ребута может просто не подняться. На хабре даже была статься по этому поводу.
В общем множество подобных ситуаций после которых так и хочется воскликнуть "какого черта?!". Со слоном я не помню ни одной такой ситуации.
2) RETURN во вставках/обновлениях. Можно получить в ответе любое поле такого запроса. И ни каких тебе танцев с LastInsertId.
3) В последних версиях есть UPSERT которого очень не хватало.
4) В целом более строгий подход и нет ощущение бардака.
5) После запуска Postgres Pro появилась полностью руссифицированная документация. Помогает вкатиться в тему новичкам.

Из минусов некоторое время было отсутствие адекватного UI клиента. Но после того, как стал использовать PhpStorm эта проблема была закрыта.

Сделайте чистый SQL запрос к базе (хоть банально из CLI) и посмотрите результат. Возможно у вас TZ соединения выставлена неправильно. В любом случае нужно начать с голого SQL запроса руками.

Вообще-то функция array_to_string принимает вторым параметром разделитель. Пример прямо в документации: www.postgresql.org/docs/9.3/static/functions-array.html

Но в целом у вас проблема с архитектурой и неправильным использованием реляционной базы. Потому что если там id записей другой таблицы, то в случае связи "многие-ко-многим" нужно просто "линковочная", промежуточная таблица.

не самое лучшее решение из-за особенностей работы openvz с shared memory.

А какие там особенности то?

А КПД будет выше того решения, которое оттюнено. Я думаю, что простая смена базы кардинально КПД не поднимет. Все же postgres больше удобнее на разработке и профиты от него сильнее чувствуются именно там.

>Сейчас там около 2 млн. записей с PK по text и обычно по нему идет поиск строки по полному совпадению.
А каким образом добавление в систему нового компонента в виде Java решит проблему? На уровне СУБД точно нет проблем? EXPLAIN точно показал, что проблем нет?

Описано довольно туманно, но чисто рефлектор на фразах «много тестовых данных» и «поиск» сразу возникает Sphinx.

Не скажу за doctrine, но запрос формата schema.table_name должен бы отрабатывать корректно. Как вариант можно перед запросом сменить текущую дефолтную схему через SET SCHEMA 'имя_схемы'

>В чём же тогда прелесть Redis-а?
Данные всегда в ОЗУ, когда как в РСУБД индекс может быть вытесняться на диск, данные при этом на больших объемах почти всегда на диске. Поэтому и получаем просадку производительности из-за I/O на диске. В Redis это в принципе нет, они сейчас на сколько я помню от виртуальной памяти отказались. Про О(1) Ghostwriter уже сказал. ACID таки вносит свой оверхед.

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