У меня два вопроса.

1. Доколе?

2. можно узнать подробнее что-нибудь про "сборку postgres" от команды 1с? что это за сборка и чем оно отличается от простого postgres?

ну нет, хотя почти да ;)

Справедливо.

а я тут запрос накорябал, может кто глянуть, что ещё докрутить можно? запрос: https://github.com/Komzpa/fastmap/blob/master/fastmap.sql эксплейн: https://github.com/Komzpa/fastmap/blob/master/explain_analyze_buffers.txt схема: https://wiki.openstreetmap.org/w/images/5/58/OSM_DB_Schema_2016-12-13.svg

монструозно. стоит разбить на хп.

2. можно узнать подробнее что-нибудь про "сборку postgres" от команды 1с? что это за сборка и чем оно отличается от простого postgres?

Есть отдельный канал в телеграме про пг для 1с

@PostgreSQL_1C_Linux 

монструозно. стоит разбить на хп.

это сделает запрос быстрее? :)

Доброго времени суток

Добрый день! А подскажите, пожалуйста, где можно почитать про момента типа когда postgres запускает перестройку индексов, как хранятся внутренние типы и тд. Postgresql under hood

Добрый день! А подскажите, пожалуйста, где можно почитать про момента типа когда postgres запускает перестройку индексов, как хранятся внутренние типы и тд. Postgresql under hood

http://rutracker.org/forum/viewtopic.php?t=5252709

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

это сделает запрос быстрее? :)

Ну если про stable не забыть, то не должно быть медленнее​. Зато код понятнее станет

после распиливания стало 12 секунд вместо 1.2, stable написан

Покажи. Может не всё так печально.

всё там же, https://github.com/Komzpa/fastmap - в explain_analyze_buffers.txt лежит угадай что :)

до 5 секунд дорезал кое-как

привет всем! подскажите, пожалуйста, в какую сторону гуглить такую ситуацию: у меня 2 таблицы: - денежные балансы пользователей - денежные транзакции на балансах по сути при созздании транзации изменяется сумма баланса (таблица с балансами является кеширующей, в плане итогового значения баланса) я понимаю, что во время создания денежной транзакции я должен локать строку баланса пользователя и пробоводить инсерт в таблице транзакций и апдейт строки в таблице балансов в одной транзакции но есть идея это все реализовать как функцию в бд, вызываюмой триггером подскажите, пожалуйста, как лучше сделать или как загуглить

Триггеры тормозить не будут, ведь триггер обработка 1 значения, а если в миллион значений и т.п., т.е. поток?

Триггеры тормозить не будут, ведь триггер обработка 1 значения, а если в миллион значений и т.п., т.е. поток?

не понял вопроса) в миллион значений что? должна быть всегда пара (инсерт транзакции, апдейт баланса)

не должно быть 5 транзакций, 1 апдейт баланса

Эм, обновление данных с сайта(пример), но сайт перерос 1-20к юзеров и теперь там 100к пользователей, не зачухается триггер с такими объёмами

понял тогда на уровне приложения стоит ставить лок, верно?

если вести все в event sourcing, то баланс и аудит транзакций сольются в единое целое с минимальными требованиями по синхронизации

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

Эм, обновление данных с сайта(пример), но сайт перерос 1-20к юзеров и теперь там 100к пользователей, не зачухается триггер с такими объёмами

у нас биллинг так балансы на триггерах и обновляет. нормально. и lock делается в хранимой процедуре которая в триггере вызывается. только там оракловая база.

зачем вообще триггера и явные блокировки на баланс? 1) не факт, что вам нужно кэширование балансов, но если реально нужно 2) клиент - begin; insert billi-op, update balalance set amount = amount + diff; commit;

зачем вообще триггера и явные блокировки на баланс? 1) не факт, что вам нужно кэширование балансов, но если реально нужно 2) клиент - begin; insert billi-op, update balalance set amount = amount + diff; commit;

Вот при апдейте может произойти расхождение

Надо блокировать строку, которая апдейтится

А так это решение и выбрал да, спасибо)

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

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

А при конкурентных запросах разве не будет ситуации, когда запишется последнее число?

begin; insert; update (ставится блокировка на строку balalance или формируетя новая версия); commit - все записано верно.

если кто-то из конкурентов опоздает обновить именно этот баланс между update; commit - получит rollback

А при конкурентных запросах разве не будет ситуации, когда запишется последнее число?

Наверно они как в 1с блокируют всю таблицу. Лол

если кто-то из конкурентов опоздает обновить именно этот баланс между update; commit - получит rollback

Хм, интересно) Надо поставить еесперемент

Проверить

почитайте на досуге про уровни изоляции транзакций и все

почитайте на досуге про уровни изоляции транзакций и все

Спасибо!

почитайте на досуге про уровни изоляции транзакций и все

да, действительно, на апдейт на строку по умолчанию ставится блокировка)

если кто-то из конкурентов опоздает обновить именно этот баланс между update; commit - получит rollback

в рид коммитед получит вейт и перезапишет очевидно человеку нужно делать +diff чтобы такого не произошло

но вы тут немного ложную надежду даете

всё там же, https://github.com/Komzpa/fastmap - в explain_analyze_buffers.txt лежит угадай что :)

Ну судя по аналайз - планировшик выбирает скан по 10млн строк (вместо 40k с nested loop) - думаю можно ещё оптимизировать.

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

А при конкурентных запросах разве не будет ситуации, когда запишется последнее число?

write skew это все-таки немного другой феномен

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

это само приложение должно сказать, а не выполняемый удаленно sql код

это само приложение должно сказать, а не выполняемый удаленно sql код

просто у меня консольная утилита принимает 2 uri: src и dest, и после установления подключения она должна себя вести немного иначе, если она общается с одним и тем же процессом через 2 подключения

дай ей дополнительный флаг запуска

дай ей дополнительный флаг запуска

эх, упрощать так упрощать

Ребята всем привет! Меня зовут Зарина, HR-менеджер компании Digsolab http://digsolab.ru Мы сейчас ищем специалиста по обработке данных и ETL-решениям на Python. - Проектирование и разработка ETL процессов на Python для наполнения DWH компании данными из различных источников (MySQL, API Google Analytics / Яндекс.Метрики, API рекламных площадок, Google Spreadsheets, лог-файлы). Сейчас мы используем для написания ETL фреймворк Luigi и аналитическую БД Amazon Redshift в качестве Data Mart. - Внедрение и поддержка разработанных решений; - Разработка систем мониторинга ключевых показателей работы бизнеса и эффективности рекламных кампаний клиентов компании. Офис: 2 мин ходьбы от ст.м. Водный стадион. Готовы рассматривать кандидатов, которые только хотят писать на питоне, или имеют мин опыт на нем, преимуществом будет опыт создания ETL систем. Присылайте резюме в личку или на почту: zarina.mulyukova@gmail.com

но вы тут немного ложную надежду даете

А почему ложную? Апдейт действительно блочит строку

Раз лок есть, то достаточно, на мой взгляд, в апдейте написать так: set amount = amount + 100 Если добавили 100 единиц денег

насколько понимаю, между SELECT x и UPDATE x = <вычисленное значение> имеет право пройти транзакция

лок на селект держится только до конца селекта

если я ничего не путаю

формат с x = x + Y должен вполне себе сработать

с +100 будет работать, с =100 получите жопу

я только об этом

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

ERROR: S client not available

я только об этом

Понял вас, спасибо!

Если кто в теме - расскажите про локи, кстати. Я знаю только то, что в основе MVCC лежат снапшоты, но, например, через какие механизмы будет отслеживаться такой конфликт - локи или идентификаторы транзакций, скажем - не знаю.

мвцц через идентификаторы

через локи это не мвцц а 2pl

2pl?

2pl?

https://en.m.wikipedia.org/wiki/Two-phase_locking

данке

https://postgrespro.ru/education/courses/DBA2 02. Изоляция транзакций 03. Страницы и версии строк 04. Снимки и блокировки

Там же ссылки на видео и материалы курса.

я пока не готов к большим объемам

А кратко про блокировки и МВЦЦ в постгресе как-то вот совсем не вырисовывается.

https://postgrespro.ru/education/courses/DBA2 02. Изоляция транзакций 03. Страницы и версии строк 04. Снимки и блокировки

Спасибо

я пока не готов к большим объемам

Там, на самом деле совсем немного.

Там, на самом деле совсем немного.

Мало того. В более сжатом виде материала по блокировкам и МВЦЦ в постгресе мне не встречалось. При этом материал вполне себе достаточен для понимания.

просто у меня консольная утилита принимает 2 uri: src и dest, и после установления подключения она должна себя вести немного иначе, если она общается с одним и тем же процессом через 2 подключения

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

есть рутовые права есть, можно соорудить такое - create TEMP table machine_id (id uuid); copy machine_id from '/etc/machine-id'; select * from machine_id;

или если можно писать, то сделать таблицу с хешом с одной стороны и дропнуть с другой

можно fdw пользовать (что по идее то же самое copy), можно plperlu и пр.

кстати, в примере с blalance update amount = amount + 100 скорее всего и блокировки жёсткой не даст, оба updatе попадут в очередь и будут выполнены по очереди на commit (грубо говоря), и не будет rollback. типичная оптимизация подобных ситуаций со стороны СУБД.

лок на селект держится только до конца селекта

Селекты вообще не блокирующие, если это не mssql?

Селекты вообще не блокирующие, если это не mssql?

если только не на реплике...

если только не на реплике...

Какого рода реплика? У нас оракл с мвью-репликами. Блокировок нет. Понятно что совсем не посгрес. Но sql стандарт должен быть одинаковый

На oracle есть ORA-01555

тут есть cron со скрипт-киллером, прям под себя

На oracle есть ORA-01555

Есть. Но это следствие CR и реализации его через undo слоты

И возникает только если те таблицы по которым идет селект очень активно меняются во время чтения

В postgres - реплике идеологически та же беда. Накатка логов меняет те таблицы по которым идёт select

Это логично. Да

И оно либо на некоторую глубину отстаёт max_standby_streaming_delay либо запрещает мастеру подчищать нужные для запроса на реплике mvcc-данные через hot_standby_feedback

Какого рода реплика? У нас оракл с мвью-репликами. Блокировок нет. Понятно что совсем не посгрес. Но sql стандарт должен быть одинаковый

Ну тут скорее сама реплика подвиснуть может. Если открыта транзакция на чтение а WAL пытается поменять/удалить запись которая должна быть видима этой транзакции .