когда fnc12 вставляет данные в tbl2 - там есть foreign key на tbl1 - и этот констрейнт вываливается, говорит нету данных таких в tbl1, хотя функция вызывается after insert

завернуто

ну так то да... есть немного... но удивляет, что возникает constraint violation

при отсутствии по уверениям PG автономных транзакций

мне нужно при вставке в tbl1 вызывать функцию fnc12, которая вставляет данные в tbl2, потом при появлении записи в tbl2 вызвать функцию в fnc23, которая вставляет в tbl3.

RULE пробовал?

https://www.postgresql.org/docs/current/static/sql-createrule.html

нет, не в курсе такого инструмента...

ейчас почитаю. спасибо за наводку

Похоже именно на твой кейс один в один

Одно дергает второе, а при вставке во второе оно дергает третье

так что получается? проверка констрейнта (tbl2 FK) делается в отдельной транзакции?

когда fnc12 вставляет данные в tbl2 - там есть foreign key на tbl1 - и этот констрейнт вываливается, говорит нету данных таких в tbl1, хотя функция вызывается after insert

Внешним ключам можно задать DEFERRED https://www.postgresql.org/docs/current/static/sql-set-constraints.html

это пробовал

не помогло

идли самим ключам?

Тогда вставлять можно даже если данных в связной таблице еще нет

я deffered вешал на триггер

Внешним ключам

а в какой момент начинается проверка тогда?

Оно будет все проверять только после коммита

Любопытно.... Нужно будет поиграться с этим. И за эту наводку спасибо

U w.

Мне с RDS может кто-нибудь помочь?)

RULE тоже не сработало - говорит нет таких данных в таблице: CREATE OR REPLACE RULE S03_TABLE1_INSERT AS ON INSERT TO S03.f_table1 WHERE NOT NEW.stat = 0 DO ALSO SELECT S03.prc_f_table1_export(NEW.f_table1);

f_table1 - primary key

функция определена как volatile

На тему пост конференциальной

Было предложение собрать людей в Питере на митапе

Собираемся!

когда? где?

Пока это абстракция

Но есть Николай с его хипстерсдб есть я кто хочет на эти темы пообщаться

Мы просто предлагаем собраться

Так что Питер, собираемся в кучку

Кому интересно в личку

Николай, с хипстерсдб – оторван от реальности. Писать прототипы круто, забавно и мило, но не для реальной жизни.

Вопрос про постгрес

Безотносительно технологий

Если оторвано от жизни давайте контрпримеры ?

тут кто-то хочет предложить перейти на mysql?

Или можете прийти и расказать

Нет вопрос в эффективности использования

Николай, когда вещал про хипстерс дб, предложил rest с регой юзеров с веба через set role, на вопрос – как он будет решать проблемы с пг баунсером, которые эти сетапы теряет – предложил баунсер не использовать.

И видимо именно поэтому все пользуют постгрес

Вопрос задан

Ищем тех кому интересно

Ищем тех кому интересно

Добавьте в инбокс. Когда это будет примерно?

Когда будем оповестим

Главное не теряться

Если будете пинговать в этот чат, то все ок

Ок

Николай, когда вещал про хипстерс дб, предложил rest с регой юзеров с веба через set role, на вопрос – как он будет решать проблемы с пг баунсером, которые эти сетапы теряет – предложил баунсер не использовать.

Я баунсер то же не использую. Если у вас язык с нормально поддержкой statefull то особой проблеммы нету.

В питере есть it meetup, там куча UG разом

Это понятно

Вопрос был про постгрес

Можно наверно туда воткнуться парой докладов и посмотреть соберется ли народ

Это обсуждалось на пгдей крайний

Люди в принципе есть

Пгдей готов подсобить с организацией, если есть добровольцы с докладами)

Интересно, а что будет быстрее работать - Seq Scan по маленькой таблице или Index Only Scan по этой же, если в нее напихать фейковых данных чтобы индекс начал использоваться?

сек

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

@korotovskii set enable_seqscan to off; и посмотри

В среднем с использовании Seq Scan оно работет 0.032 ms. При использовании индекса 0.068 ms в среднем.

Постгрес всех перехитрил.

Просто такие запросы портят статистику кол-ва Seq Scan на таблицах в мониторинге )

а почему это считается проблемой?

так ничего плохого в секскане нет, иногда он эффективнее даже на больших таблицах

в много потоков synchronized seq scan ещё бывает, он тоже хорош

а почему это считается проблемой?

Приходится разбираться, это разработчик добавил очередной Seq Scan из за "тяп-ляп" в ORM или это тот самый запрос, который будет работать эффективнее в режиме Seq Scan/

так а как насчёт смотреть на скорость исполнения вместо этого?

Некоторые запросы могут работать до 100мс, что часто приемлимо, но с надлежащими индексами и/или перестроением запроса - работает до 90% быстрее.

Измерение скорости не панацея.

в рамках одной таблицы ?

Или нескольких

Все зависит от масштаба релиза :)

Не, я просто про то, что у нас SLA к таблице как бы.

Можно наверное считать кол-во сексканов сутки

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

Но тогда аларм будет только через сутки :(

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

Ну ты же понимаешь у меня тут вёб, rapid growing company и все такое.

Иногда на ревью мимо меня ускользает очередной кривой запрос, порожденный ORM.

ну ок) тогда не знаю.

в rapid growing companies смотрят в iops / cpu на инстансе с базой и поднимают ещё один, когда не хватает :)

Идеология в компании такая - есть один "умненький" и десяток середнечков формошлепчиков.

в rapid growing companies смотрят в iops / cpu на инстансе с базой и поднимают ещё один, когда не хватает :)

вобще поддерживаю )

в rapid growing companies смотрят в iops / cpu на инстансе с базой и поднимают ещё один, когда не хватает :)

Я лучше эту разницу себе в карман попрошу. Никаких денег не хватит на RDS в амазоне при таком подходе.

А видели в 4.7 изменения в мемори менеджменте с отсылкой к PG ? )

*в 4.7 ядре

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

Как то решил выделить день на оптимизации костов для базы. Оптимизировли CPU так, что в итоге сэкономили порядка ~10тыс только в год на этом.

У нас запас по производительности ~75%.

Вопрос, а вы инстансе в пике на какой нагрузке стараетесь держать ?

20-25%

если нужно читать большую часть таблицы - seq scan будет эффективнее независимо от ее размеров. Потому, что он простой, как валенок. А с индексом там еще куча нюансов может быть.

индекс выгоднее если селективность выше 2%, такое измерение встречал

А видели в 4.7 изменения в мемори менеджменте с отсылкой к PG ? )

Где смотреть?