@evgenbal будет жить. Поприветствуем!

Всем привет. Народ вопрос про нагрузки. База постгрес. без индексов. Какой запрос создаст большую нагрузку на сервер: Один с сохранением миллиона записей (в рамках одной транзакции), или 200 (подряд, синхронно) по 5000 записей?

И тот же вопрос если есть индексация (например на одну колонку)

Это то что называют новомодным словом forensic.

Эммм, а для старых пердунов, в каком значении данное словцо используется? А то я в словаре штук пять этих значений наблюдаю.

Это когда приходит KGB и начинает перлюстрировать перфокарты. Не заботясь о сохранении их последовательности и целостности.

@VViiittt будет жить. Поприветствуем!

Всем привет. Народ вопрос про нагрузки. База постгрес. без индексов. Какой запрос создаст большую нагрузку на сервер: Один с сохранением миллиона записей (в рамках одной транзакции), или 200 (подряд, синхронно) по 5000 записей?

По идее, это +- одно и тоже. Разве что какая-то нестандартная ситуация...

Всем привет. Народ вопрос про нагрузки. База постгрес. без индексов. Какой запрос создаст большую нагрузку на сервер: Один с сохранением миллиона записей (в рамках одной транзакции), или 200 (подряд, синхронно) по 5000 записей?

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

если реплик нет

второе будет медленнее по-любому

@darkfelex будет жить. Поприветствуем!

@Zolegzz будет жить. Поприветствуем!

@algost будет жить. Поприветствуем!

Всем привет. Ребят кто использовал ON CONFLICT. Столкнулся с такой проблемой. Вот такой запрос `INSERT INTO users_calculated_parameters (user_id, calculated_parameter_id, value) VALUES (1, 2, 30) ON CONFLICT (user_id, calculated_parameter_id) DO UPDATE SET value = excluded.value` - Конфликт может возникать когда уже есть запись с таким user_id и calculate_id(такая реализация upsert) НО конфликт еще может возникнуть из за foreign key user_id, когда пользователя просто нет, МОЖНО ЛИ сделать несколько ON CONFLICT к одному Insert?

Приветсвую всех, поставили stolon и чистый postgresql, с одинаковыми настройками и одинаковой версией, только postgresql на одной железке а stolon на 3 нодах (3 железяках) проводил разные тесты, но на чисттом pos pgbench -c 500 -T 300 -S -j 4 -P 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 14183823 latency average = 10.531 ms latency stddev = 2.097 ms tps = 47262.555691 (including connections establishing) tps = 47264.141290 (excluding connections establishing) а у stolon на тех же тестах производительность отличается практичесски на порядок в тех же тестах: pgbench -c 500 -T 300 -S -j 4 -P 10 Password: starting vacuum...end. scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 1784407 latency average = 83.873 ms latency stddev = 226.166 ms tps = 5878.774755 (including connections establishing) tps = 5878.918058 (excluding connections establishing)

причём и латенция у столон заметно хуже и количество tps меньше Это так и должно быть или как то используем неправильно?

wal_level какой на разных конфигурациях?

Это неинтересно и не вариант в производственной среде. Это рукоблудие и красноглазие в особотяжелой и опасной для окружающих форме. По вашему вопросу: того, что вам хочется нет.

Интересно для меня с точки зрения внутренней архитектуры этого всего.

wal_level какой на разных конфигурациях?

wal_level=replica

Интересно для меня с точки зрения внутренней архитектуры этого всего.

gdb-ой в потрохах ПГ поковыряться? Годное развлечение. В среде разработки или тестовой.

wal_level=replica

Случайно репликация синхронная?

Случайно репликация синхронная?

synchronous_commit=On synchronous_standby_names= пустой

или ещё что то можно посомтреть что коммиты синхронные?

Действительно не синхронная. Странно

Приветсвую всех, поставили stolon и чистый postgresql, с одинаковыми настройками и одинаковой версией, только postgresql на одной железке а stolon на 3 нодах (3 железяках) проводил разные тесты, но на чисттом pos pgbench -c 500 -T 300 -S -j 4 -P 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 14183823 latency average = 10.531 ms latency stddev = 2.097 ms tps = 47262.555691 (including connections establishing) tps = 47264.141290 (excluding connections establishing) а у stolon на тех же тестах производительность отличается практичесски на порядок в тех же тестах: pgbench -c 500 -T 300 -S -j 4 -P 10 Password: starting vacuum...end. scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 1784407 latency average = 83.873 ms latency stddev = 226.166 ms tps = 5878.774755 (including connections establishing) tps = 5878.918058 (excluding connections establishing)

а что такое stolon, это прокси перед postgres?

это фейловер типа

угу, не понимаю как фейловер связан с TPS, он видимо как прокси стоит перед сервером?

второе будет медленнее по-любому

Зато долго транзакции не будет, всякие вакумы и минивакумы будут рады

угу, там proxy: https://raw.githubusercontent.com/sorintlab/stolon/master/doc/architecture_small.png

Приветсвую всех, поставили stolon и чистый postgresql, с одинаковыми настройками и одинаковой версией, только postgresql на одной железке а stolon на 3 нодах (3 железяках) проводил разные тесты, но на чисттом pos pgbench -c 500 -T 300 -S -j 4 -P 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 14183823 latency average = 10.531 ms latency stddev = 2.097 ms tps = 47262.555691 (including connections establishing) tps = 47264.141290 (excluding connections establishing) а у stolon на тех же тестах производительность отличается практичесски на порядок в тех же тестах: pgbench -c 500 -T 300 -S -j 4 -P 10 Password: starting vacuum...end. scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 1784407 latency average = 83.873 ms latency stddev = 226.166 ms tps = 5878.774755 (including connections establishing) tps = 5878.918058 (excluding connections establishing)

ну удачи в отладке :-)

Приветсвую всех, поставили stolon и чистый postgresql, с одинаковыми настройками и одинаковой версией, только postgresql на одной железке а stolon на 3 нодах (3 железяках) проводил разные тесты, но на чисттом pos pgbench -c 500 -T 300 -S -j 4 -P 10 starting vacuum...end. transaction type: <builtin: select only> scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 14183823 latency average = 10.531 ms latency stddev = 2.097 ms tps = 47262.555691 (including connections establishing) tps = 47264.141290 (excluding connections establishing) а у stolon на тех же тестах производительность отличается практичесски на порядок в тех же тестах: pgbench -c 500 -T 300 -S -j 4 -P 10 Password: starting vacuum...end. scaling factor: 1 query mode: simple number of clients: 500 number of threads: 4 duration: 300 s number of transactions actually processed: 1784407 latency average = 83.873 ms latency stddev = 226.166 ms tps = 5878.774755 (including connections establishing) tps = 5878.918058 (excluding connections establishing)

RTT между proxy-нодой и мастер-нодой какой?

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

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

Репликация там походу вообще асинхронная

о, давайте начнем дискусcию "понятия 'синхронная репликация' не существует"

Репликация там походу вообще асинхронная

Вы имеете в виду в конкретно этом случае или вообще в stolon?

Вы имеете в виду в конкретно этом случае или вообще в stolon?

В этом, параметр пг synchronousStandbyNames пуст

о, давайте начнем дискусcию "понятия 'синхронная репликация' не существует"

В смысле?

В этом, параметр пг synchronousStandbyNames пуст

Он по умолчанию равен 1. А что говорит synchronousReplication?

Он по умолчанию равен 1. А что говорит synchronousReplication?

Вангую, что параметр столон synchronousReplication стоит в false, т.к. в пг параметр строки с синхронными репликами пуст

Stolon создаёт новый кластер при инициализации. Я бы убедился, что конфиг действительно используется тот, в который смотрят) Ещё есть предположение, что подключаются к одному из 3х proxy, который находится на другой машине, не там где primary. Можно просто подключиться к primary напрямую и прогнать тест.

добрый вечер, други я вчера задавал вопрос про psycopg2 с постгресом вообщем я докопался до того, что у нас при выборке данных постгрес постоянно шмыгает по диску открыл strace и вижу, что на каждые 8 килобайт считанных с диска он затем снова устанавливает поинтер в рандомное место на диске и из-за этого получаются тормоза кто-нибудь знает, с чем это связано? причем, если выбрать ну тысяч 20 данных, а потом перезапустить процесс выборки (ну то есть сделать тупо стоп и старт) - то seek'и прекратятся и данные нормально начнут забираться, если не перезапускать первый процесс - то и 20++к данные так же вызывают seek

В смысле?

Ну она по определению всегда асинхронная, кто-то всегда коммитит раньше

Ну она по определению всегда асинхронная, кто-то всегда коммитит раньше

Ну и что? Главное, что реплики commit-ят до того, как commit заканчивается на master. Я, может, подзабыл, но разве это не всё, что требуется от синхронной репликации?

Ну и что? Главное, что реплики commit-ят до того, как commit заканчивается на master. Я, может, подзабыл, но разве это не всё, что требуется от синхронной репликации?

Это не синхронная репликация ???

Всем привет! #вакансия #it #удаленка #php #backend #postgresql Компания Skyeng ищет на постоянную удаленную работу backend-разработчиков, которые помогут нам в развитии многочисленного функционала сервиса. Сегодня мы являемся самой крупной языковой онлайн-школой в Восточной Европе и быстро развиваемся. Мы ждем от разработчика - Общий опыт разработки — не менее 3 лет - Основные бэкенд технологии: PHP, Symfony, Doctrine, PostgreSQL, Elasticsearch, RabbitMQ. - Иметь опыт разработки проектов под существенную нагрузку Мы работаем в московском часовом поясе, разговариваем в Slack и в Hangouts, пишем документацию в Confluence, задачи складываем в Jira, код в GitHub, а для CI/CD используем Jenkins и Capistrano. Что мы даем взамен - Зарплата до 160 000 руб. на руки - Возможность учиться: регулярные доклады разработчиков внутри компании, участие и выступления на конференциях, а также много крутых специалистов :) - Недавно мы провели первый хакатон и не собираемся останавливаться - Скидка 50% на уроки английского вам и вашему другу Контакт: @bykatya https://hh.ru/vacancy/27796608

Это не синхронная репликация ???

Почему? По какому определению, у Вас ссылки не найдётся? (А то я в самом деле забыл). ;)

А вот и release v11: https://www.postgresql.org/about/news/1894/

Хей. Ситуация: при коннекте с помощью psql к базе все ок. При коннекте из Golang, postgres throw 'role abcd' doesn't exist psql -> \dg говорит, что роль 'abcd' существует. Проверил конфиг коннекта к базе, имя роли совпадает

Сори, если слегка оффтоп.

Stolon создаёт новый кластер при инициализации. Я бы убедился, что конфиг действительно используется тот, в который смотрят) Ещё есть предположение, что подключаются к одному из 3х proxy, который находится на другой машине, не там где primary. Можно просто подключиться к primary напрямую и прогнать тест.

+1 @chamav прогоните бенч, смотрящий непосредственно на мастер

Почему? По какому определению, у Вас ссылки не найдётся? (А то я в самом деле забыл). ;)

интересно, что такое синхронность?

интересно, что такое синхронность?

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

да нет, термин всегда однозначен

Хей. Ситуация: при коннекте с помощью psql к базе все ок. При коннекте из Golang, postgres throw 'role abcd' doesn't exist psql -> \dg говорит, что роль 'abcd' существует. Проверил конфиг коннекта к базе, имя роли совпадает

белая зависть!)) у нас гомосятину в стек не пускают, говорят писать на том, на чем пишут фсе ?

белая зависть!)) у нас гомосятину в стек не пускают, говорят писать на том, на чем пишут фсе ?

А на чем все пишут нынче?..

А на чем все пишут нынче?..

?

?

На зелёных уточках?

А

Мое зрение, Боги На пайтоне

зелёные уточки тоже не плохо)) интересно, а тут ругаются за флуд и оффтом ?

зелёные уточки тоже не плохо)) интересно, а тут ругаются за флуд и оффтом ?

Простите, наркоман совсем. Если не секрет, у вас Джанга или что-то асинхронное?

да нет, термин всегда однозначен

Термин-то однозначен. А вот то, что "интуитивно" следует из его прочтения, зачастую мало относится к определяемому понятию.

Простите, наркоман совсем. Если не секрет, у вас Джанга или что-то асинхронное?

Django, Flask, Postgres, openVINO, vue, centos7, ubuntu 16 асинхронное (iohttp) не пускают по тем же причинам что и го типа скейлиться будем на виртуалках, докер тоже не прошёл)))))) мы как мажоры, 1 микросервис = 1 виртуалка

Django, Flask, Postgres, openVINO, vue, centos7, ubuntu 16 асинхронное (iohttp) не пускают по тем же причинам что и го типа скейлиться будем на виртуалках, докер тоже не прошёл)))))) мы как мажоры, 1 микросервис = 1 виртуалка

Да простят мне оффтоп, но Джангу не люблю, от слова совсем. Модели сами генерируют SQL, и не всегда этот SQL оптимален И прочая магия Джанго: пишем команду create admin, создаётся админка.. Это не холивар, если что, питон незаменим в известных областях, моя неприязнь лишь направленна на философию фреймворка П.С. а у нас отказались от кубернетиса и слепили свой: cheff, nomad, consul, consul template, etc П.С.С не завидую Вам :(

Ребят, у меня есть 18-значное число, у которого еще N разрядов есть (т.е. число может быть и 30-значным). А в pgsql бигинт - 19 знаков. Как мне быть? Как уложить настолько большое число в БД?

Процедуры и анонимные блоки всегда одной транзакцией выполняются, увы.

Теперь нет: https://www.postgresql.org/about/news/1894/

Ребят, у меня есть 18-значное число, у которого еще N разрядов есть (т.е. число может быть и 30-значным). А в pgsql бигинт - 19 знаков. Как мне быть? Как уложить настолько большое число в БД?

строка не подходит, т.к. нужно использовать сравнение чисел в условиях

Ребят, у меня есть 18-значное число, у которого еще N разрядов есть (т.е. число может быть и 30-значным). А в pgsql бигинт - 19 знаков. Как мне быть? Как уложить настолько большое число в БД?

numeric(n, 0)

зелёные уточки тоже не плохо)) интересно, а тут ругаются за флуд и оффтом ?

Это ж не ваш коммунистический sqlcomru))

какие люди) Hello Igor ну да, мы коммунисты, это плохо ?) у нас вообще-то под оффтоп отдельный канал есть

numeric(n, 0)

Благодарю

:)

Да простят мне оффтоп, но Джангу не люблю, от слова совсем. Модели сами генерируют SQL, и не всегда этот SQL оптимален И прочая магия Джанго: пишем команду create admin, создаётся админка.. Это не холивар, если что, питон незаменим в известных областях, моя неприязнь лишь направленна на философию фреймворка П.С. а у нас отказались от кубернетиса и слепили свой: cheff, nomad, consul, consul template, etc П.С.С не завидую Вам :(

а какие аргументы против кубернетиса ? swarm смотрели?

добрый вечер, други я вчера задавал вопрос про psycopg2 с постгресом вообщем я докопался до того, что у нас при выборке данных постгрес постоянно шмыгает по диску открыл strace и вижу, что на каждые 8 килобайт считанных с диска он затем снова устанавливает поинтер в рандомное место на диске и из-за этого получаются тормоза кто-нибудь знает, с чем это связано? причем, если выбрать ну тысяч 20 данных, а потом перезапустить процесс выборки (ну то есть сделать тупо стоп и старт) - то seek'и прекратятся и данные нормально начнут забираться, если не перезапускать первый процесс - то и 20++к данные так же вызывают seek

похоже на доступ по индексу

похоже на доступ по индексу

Там нет индекса, там табличка с одним полем id

а какие аргументы против кубернетиса ? swarm смотрели?

Я, конечно не DevOps.. В devops-чатике объяснялось все, как желание полного контроля. И каких-то возможностей "кубик" не предоставлял. Но первый аргумент был самым весомым - тотальный контроль всего и вся.

Там нет индекса, там табличка с одним полем id

И что? Покажите запрос, EXPLAIN (ANALYZE, BUFFERS), и \d таблицы.

И что? Покажите запрос, EXPLAIN (ANALYZE, BUFFERS), и \d таблицы.

IMHO лучше это https://postgrespro.ru/docs/postgresql/10/auto-explain

Мало ли как ведет себя psycopg2 в дикой природе

IMHO лучше это https://postgrespro.ru/docs/postgresql/10/auto-explain

Да для одного простого запроса это как-то чересчур. Кроме того, \d нужно всё равно.