в text возможно скастить надо

Угу, именно так и надо было PERFORM pg_notify('watchers', cast(NEW.id || ', '|| NEW.fam AS text));

За юзера А создал словарь и конфигурацию, как дать возможность пользоваться ими юзеру Б ? изменить владельца pg_ts_config / pg_ts_dict ?

ребят, всем привет! подскажите пожалуйста, есть такой кейс: на сервере стояла неправильная таймзона, следовательно поля created_at имеют значение времени на 1 час меньше, чем нужно. нужно в конкретной базе обновить во всех таблицах поля типа timestamp without time zone (увеличить на 1 час)

кто-то может подсказать, как это сделать максимально просто?)

Добрый день! Господа, помогите советом. Есть 15000 одновременно работающих пользователей (очень грубо говоря 8000 запросов в секунду). 70% читают 30% инсертят. Данных пока 2-3 млн записей. Нужно сделать чтобы Postgre выжил от таких нагрузок и возвращал/вставлял данные за приемлемеое время (1-2 сек на запрос). Думаем размазать данные на шарды, каждую шарду реплицировать, писать в мастер, читать со слэйвов. И видим два варианта как к этому подойти: 1. Переложить на всю логику доступа к шардам на приложение. Чтобы оно могло в явном виде писать данные в нужный шард и читать из нужного шарда. 2. Поднять кластер Postgres-XL + pgpool. Буду весьма признателен если сможете посоветовать в какую сторону лучше смотреть. Быть может проблема надумана и с этим справится и один инстанс? Заранее благодарю!

Добрый день! Господа, помогите советом. Есть 15000 одновременно работающих пользователей (очень грубо говоря 8000 запросов в секунду). 70% читают 30% инсертят. Данных пока 2-3 млн записей. Нужно сделать чтобы Postgre выжил от таких нагрузок и возвращал/вставлял данные за приемлемеое время (1-2 сек на запрос). Думаем размазать данные на шарды, каждую шарду реплицировать, писать в мастер, читать со слэйвов. И видим два варианта как к этому подойти: 1. Переложить на всю логику доступа к шардам на приложение. Чтобы оно могло в явном виде писать данные в нужный шард и читать из нужного шарда. 2. Поднять кластер Postgres-XL + pgpool. Буду весьма признателен если сможете посоветовать в какую сторону лучше смотреть. Быть может проблема надумана и с этим справится и один инстанс? Заранее благодарю!

Очень грубо говоря, получается что ваше приложение работало ~20 минут ?

1 вариант конечно должен быть

Добрый день! Господа, помогите советом. Есть 15000 одновременно работающих пользователей (очень грубо говоря 8000 запросов в секунду). 70% читают 30% инсертят. Данных пока 2-3 млн записей. Нужно сделать чтобы Postgre выжил от таких нагрузок и возвращал/вставлял данные за приемлемеое время (1-2 сек на запрос). Думаем размазать данные на шарды, каждую шарду реплицировать, писать в мастер, читать со слэйвов. И видим два варианта как к этому подойти: 1. Переложить на всю логику доступа к шардам на приложение. Чтобы оно могло в явном виде писать данные в нужный шард и читать из нужного шарда. 2. Поднять кластер Postgres-XL + pgpool. Буду весьма признателен если сможете посоветовать в какую сторону лучше смотреть. Быть может проблема надумана и с этим справится и один инстанс? Заранее благодарю!

Вам всё это точно надо? Вроде бы не очень интересный сервер должен с таким справляться.

Добрый день! Господа, помогите советом. Есть 15000 одновременно работающих пользователей (очень грубо говоря 8000 запросов в секунду). 70% читают 30% инсертят. Данных пока 2-3 млн записей. Нужно сделать чтобы Postgre выжил от таких нагрузок и возвращал/вставлял данные за приемлемеое время (1-2 сек на запрос). Думаем размазать данные на шарды, каждую шарду реплицировать, писать в мастер, читать со слэйвов. И видим два варианта как к этому подойти: 1. Переложить на всю логику доступа к шардам на приложение. Чтобы оно могло в явном виде писать данные в нужный шард и читать из нужного шарда. 2. Поднять кластер Postgres-XL + pgpool. Буду весьма признателен если сможете посоветовать в какую сторону лучше смотреть. Быть может проблема надумана и с этим справится и один инстанс? Заранее благодарю!

1-2 секунды на запрос это очень долго. Если, конечно, запросы не слишком уж сложные.

Для десктопа с не очень старым Intel процессором и пользовательским SSD pgbench даёт >4000 tps на ядро.

Очень грубо говоря, получается что ваше приложение работало ~20 минут ?

Думаю я не правильно выразился. Есть 15к работающих пользователей, все они что то делают, отправляют запросы на сервер. И может случиться такая ситуация, что скажем 8к пользователей одновременно захотят что то сделать. В этом случае производительность не должна катастрофически просесть

Думаю я не правильно выразился. Есть 15к работающих пользователей, все они что то делают, отправляют запросы на сервер. И может случиться такая ситуация, что скажем 8к пользователей одновременно захотят что то сделать. В этом случае производительность не должна катастрофически просесть

такое единовременное воляизъявление возможно только на выборах, реально 15к работающих пользователей != 15к rps. Смотрите на текущий профиль нагрузки, сделайте перформанс тесты и посмотрите, но, обычно, PostgreSQL достаточно много "держит".

Думаю я не правильно выразился. Есть 15к работающих пользователей, все они что то делают, отправляют запросы на сервер. И может случиться такая ситуация, что скажем 8к пользователей одновременно захотят что то сделать. В этом случае производительность не должна катастрофически просесть

количество открытых транзакций не может превышать max_connections, думаю это понятно

Ок. Спасибо. Скорее всего я преувеличиваю и реально в один момент времени будет 500-1000 транзакций, и наверное с этим справится и один интсанс. Но все-таки интересен момент с шардированием. Скажем данные будут прирастать очень быстро (500к в неделю), данные можно разделить по категориям и раскинуть на шарды. Видел реализацию шардирования через вьюху на основной ноде (чтение и запись через нее). Нормально ли использовать такой вариант, или все-таки заморачиваться и городить все это в аппликейшене. В целом хотелось бы, чтобы для приложения все шарды выступали как один инстанс БД. Не размазывать управление шардами между приложением и СУБД.

Ок. Спасибо. Скорее всего я преувеличиваю и реально в один момент времени будет 500-1000 транзакций, и наверное с этим справится и один интсанс. Но все-таки интересен момент с шардированием. Скажем данные будут прирастать очень быстро (500к в неделю), данные можно разделить по категориям и раскинуть на шарды. Видел реализацию шардирования через вьюху на основной ноде (чтение и запись через нее). Нормально ли использовать такой вариант, или все-таки заморачиваться и городить все это в аппликейшене. В целом хотелось бы, чтобы для приложения все шарды выступали как один инстанс БД. Не размазывать управление шардами между приложением и СУБД.

а откуда берётся в изначальном посте "1-2 сек на запрос" вообще?

Ок. Спасибо. Скорее всего я преувеличиваю и реально в один момент времени будет 500-1000 транзакций, и наверное с этим справится и один интсанс. Но все-таки интересен момент с шардированием. Скажем данные будут прирастать очень быстро (500к в неделю), данные можно разделить по категориям и раскинуть на шарды. Видел реализацию шардирования через вьюху на основной ноде (чтение и запись через нее). Нормально ли использовать такой вариант, или все-таки заморачиваться и городить все это в аппликейшене. В целом хотелось бы, чтобы для приложения все шарды выступали как один инстанс БД. Не размазывать управление шардами между приложением и СУБД.

Всего лишь 500к? Для этого не нужно мучиться с шардами.

какие запросы у вас настолько медленные?

а откуда берётся в изначальном посте "1-2 сек на запрос" вообще?

Наверное везде distinct понаставили

Ок. Спасибо. Скорее всего я преувеличиваю и реально в один момент времени будет 500-1000 транзакций, и наверное с этим справится и один интсанс. Но все-таки интересен момент с шардированием. Скажем данные будут прирастать очень быстро (500к в неделю), данные можно разделить по категориям и раскинуть на шарды. Видел реализацию шардирования через вьюху на основной ноде (чтение и запись через нее). Нормально ли использовать такой вариант, или все-таки заморачиваться и городить все это в аппликейшене. В целом хотелось бы, чтобы для приложения все шарды выступали как один инстанс БД. Не размазывать управление шардами между приложением и СУБД.

А раз Вы готовы шардировать, ACID Вам не нужен, я правильно понял? Почему бы не попробовать поотключать всё с ним связанное (кроме fsync), да и не протестировать?

Ок. Спасибо. Скорее всего я преувеличиваю и реально в один момент времени будет 500-1000 транзакций, и наверное с этим справится и один интсанс. Но все-таки интересен момент с шардированием. Скажем данные будут прирастать очень быстро (500к в неделю), данные можно разделить по категориям и раскинуть на шарды. Видел реализацию шардирования через вьюху на основной ноде (чтение и запись через нее). Нормально ли использовать такой вариант, или все-таки заморачиваться и городить все это в аппликейшене. В целом хотелось бы, чтобы для приложения все шарды выступали как один инстанс БД. Не размазывать управление шардами между приложением и СУБД.

Каждый день одна из таблиц растет более чем на 1 млн записей -- полет на одном сервере нормальный. ;)

Посмотрите, может в вашем случае можно смаштабировать с помощью plproxy

а откуда берётся в изначальном посте "1-2 сек на запрос" вообще?

это в пиках нагрузки. запрос должен отрабатывать не более 1-2 сек (это гипотетические цифры). запрос на самом деле простой. 4-5 джоинов + фильтрация по наименованию лайком. Спасибо всем. В общем будем пробовать, и смотреть что получится.

Каждый день одна из таблиц растет более чем на 1 млн записей -- полет на одном сервере нормальный. ;)

Alexander , а сколько пользователей работает с вашей БД. Какое максимальное колличество коннектов разрешено?

Alexander , а сколько пользователей работает с вашей БД. Какое максимальное колличество коннектов разрешено?

Разрешено 1000, но из-за того, что запросы выполняются очень быстро, количество активных редко скачет выше 20. Средняя нагрузка около 6-8k TPS.

Таблица, о которой я писал вам выше, сейчас содержит около 220 млн записей. По ней постоянно идут маленькие join и достаточно обильно добавляются новые записи. Если хотите - напишите в лс, чуть подробнее расскажу о ситуации и нагрузке :)

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

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

Ого. Даже не подумал бы, что это критично. Вы правы. Спасибо.

Поэтому либо: 1. Создайте сначала groups, а потом те таблицы, чьи поля будут ссылаться на поля из groups 2. Создайте связь между полями отдельно внизу, уже после создания всех таблиц, которые там используются

Пожалуйста ;)

За второй совет отдельное спасибо)

За второй совет отдельное спасибо)

Пожалуйста. Кстати, IntelliJ позволяет вам изменять схему таблицы с помощью красивого GUI, ниже создавая соответствующий SQL-запрос, который сделает все то, что вы "накликали" руками. ;)

Пожалуйста. Кстати, IntelliJ позволяет вам изменять схему таблицы с помощью красивого GUI, ниже создавая соответствующий SQL-запрос, который сделает все то, что вы "накликали" руками. ;)

Не не не. Я только учусь. Хочу ручками все пописать.

Не не не. Я только учусь. Хочу ручками все пописать.

Да даже когда научитесь всё равно лучше ручками )

Да даже когда научитесь всё равно лучше ручками )

Согласен)

Привет всем. У меня вопрос: есть две бд с одинаковой схемой. В одной (к примеру бд2) есть данные за все время до вчера. В другой (бд1) есть данные за все время + риалтайм данные за сегодня и тп. Как перенести разницу данных на бд2 с бд1?

Думаю только полным дампом с бд1

По дате фильтрануть и залить через fdw

да можно и копи сделать с условием по дате.

Подскажите пожалуйста, почему конфиги/словари для fts не видны в другой базе от одного и того же юзера ? хотя в pg_ts_config / pg_ts_dict dictowner совпадает с id юзера

Подскажите пожалуйста, почему конфиги/словари для fts не видны в другой базе от одного и того же юзера ? хотя в pg_ts_config / pg_ts_dict dictowner совпадает с id юзера

Конфиги и словари нужно создавать для каждой базы отдельно, как и другие объекты базы

Да, уже разобрался, а через схемы можно как-нибудь сделать "общие" конфиги/словари для разных баз?

по-моему тоже нельзя, т.к. схемы тоже не шарятся между базами

Всем привет! Есть колонка, числовая, в ней возрастающие значения. Нужно найти все пропуски. Напрмер, идут значения 1,2,5,6. 3 и 4 - это пропуски

Что-то типа select i from generate_series(1,6) s(i) except select id from table;

Всем привет! Есть колонка, числовая, в ней возрастающие значения. Нужно найти все пропуски. Напрмер, идут значения 1,2,5,6. 3 и 4 - это пропуски

select * from generate_series(1, N) as x where x not in (select id from ваша_таблица)

select * from generate_series(1, N) as x where x not in (select id from ваша_таблица)

О, спасибо!

с except может быть быстрее, не ?

except похоже хорошая штука, не знал про нее

если значения не повторяются лучше делать except all

Всем привет! Есть колонка, числовая, в ней возрастающие значения. Нужно найти все пропуски. Напрмер, идут значения 1,2,5,6. 3 и 4 - это пропуски

Если данных много и поле индесировано, можно ещё попробовать что-нибудь с оконными функциями.

Если данных много и поле индесировано, можно ещё попробовать что-нибудь с оконными функциями.

Ага, спасибо!

Если данных много и поле индесировано, можно ещё попробовать что-нибудь с оконными функциями.

Чем человеку поможет индекс, если ему в любом случае все строки из таблицы выбирать?

Чем человеку поможет индекс, если ему в любом случае все строки из таблицы выбирать?

Не все строки, а только проиндексированный столбец.

Чем человеку поможет индекс, если ему в любом случае все строки из таблицы выбирать?

И что? Во-первых, я не знаю какой в ней средний размер записи, а, во-вторых, индекс —- это возможность получить уже отсортированные значения (полезная для этой задачи).

Привет всем. Кто сталкивался с Sorry. Too many clients already. с Postgres 9.6 в докере + PgBouncer?

Привет всем. Кто сталкивался с Sorry. Too many clients already. с Postgres 9.6 в докере + PgBouncer?

А вопрос-то в чём?

Как это пофиксить?

И что? Во-первых, я не знаю какой в ней средний размер записи, а, во-вторых, индекс —- это возможность получить уже отсортированные значения (полезная для этой задачи).

Про сортировку согласен.

Насколько я понимаю, это пг не дропает коннекты, которые неактивны, max_connection стоит 100

и забивается

Насколько я понимаю, это пг не дропает коннекты, которые неактивны, max_connection стоит 100

А разве это дело PostgreSQL в этой конфигурации? Я думал, что pgbouncer должен сам этим управлять...

Может быть старый PgBouncer

Может быть старый PgBouncer

Ну а Вы логи PgBouncer-а смотрели? А если в его консоли попробовать посмотреть SHOW CLIENTS / SERVERS / POOLS и т.п.?

Какой размер пула на pgbouncer ?

дефолтный, он тоже в контейнере

А можно цифру узнать? И сравнить с max_connection. А то libastral не подгружается...

сейчас вскрою конфиги

может стоит переключить pool_mode с session на transaction

?

default_pool_size = 20

можно увеличить эту цифру, к примеру до 100-200 и изменить мод

И чем это поможет?

можно увеличить эту цифру, к примеру до 100-200 и изменить мод

А Вы уверены, что в transaction pooling mode приложения вообще смогут работать?

Если у вас есть prepared транзакции вы рискуете сломать приложение

нет, предполагаю

А Вы уверены, что в transaction pooling mode приложения вообще смогут работать?

У нас работает, но мы специально адаптировали приложение

чем transaction мод может сломать приложение?

чем transaction мод может сломать приложение?

Это описано в FAQ pgbouncer. Вы что, на production хотите так экспериментировать? ;)

пока на деве, но иногда приходится перезапускать контейнер с Postgres, когда забьются коннекты

Количество max_connecntion должно быть больше default_pool_size. Иначе вы получите то, что получаете.

А вы уверены, что у вас приложение ходит через баунсер? show fds что показывает?

пока на деве, но иногда приходится перезапускать контейнер с Postgres, когда забьются коннекты

Ну так лучше разберитесь, почему это происходит. Может, Ваши приложения не закрывают соединения, или, хуже того, транзакции. ;)

уверен

Значит вам надо понять, что потребляет коннекты. При размере пула 20 у вас не может быть больше 20 коннектов на БД от баунсера к базе

Фреймворк должен это делать, покрайне мере в доках так написано =)

спасибо, смотрю

Сколько баз у вас в кластере?

Учитывайте, что если на серваке несколько баз, то число коннектов= количество БД * размер пула