Скину сюда через полтора часа ddl, предметно обсудим)

ну я спать) завтра почитаю

Скину сюда через полтора часа ddl, предметно обсудим)

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

нежели если бы эти данные были бы в одном месте

Здравствуйте ставлю на сентос6.9 постгрес 9.6

runuser: невозможно установить группы: Операция не позволяется

я понял что пользователь postgres не может службу запустить из-за selinux как его настроить?

я понял что пользователь postgres не может службу запустить из-за selinux как его настроить?

Так же как в 99% мануалов - открываешь /etc/selinux/config и прописываешь там disabled.

опасный путь предлагаешь ты.

опасный путь предлагаешь ты.

на темную сторону selinux отключение ведет?

Так же как в 99% мануалов - открываешь /etc/selinux/config и прописываешь там disabled.

пусть лучше пермиссив будет )

Всем привет! У кого-то есть опыт настройки репликации между PostgreSQL и tarantool?

Всем привет! У кого-то есть опыт настройки репликации между PostgreSQL и tarantool?

репликации?!

хочу попробовать поставить тарантул в качестве кеша перед постгресом

хочу попробовать поставить тарантул в качестве кеша перед постгресом

тебя ни капли не смущает что тарантул nosql ?

поэтому и пробую ?

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

А в постгре можно создавать индексы по вложенным свойствам jsonb-полей?

В постгресе есть бсон?

Дыа. =)

ой тьфу.

jsonb

Монгодб головного мозга.

А в постгре можно создавать индексы по вложенным свойствам jsonb-полей?

Ну так можно?

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

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

А если оно просто хранится в таблице?

Прямо в таком виде.

Ну так можно?

https://www.postgresql.org/docs/current/static/datatype-json.html#JSON-INDEXING

https://www.postgresql.org/docs/current/static/datatype-json.html#JSON-INDEXING

Пардон. И спасибо. =)

опасный путь предлагаешь ты.

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

Когда у вас в таблице 100500*n записей, то выгоднее, с точки зрения оптимизации, телефон держать не в отдельной сущности, а в денормализованном виде

Это как? В массиве? У меня вот, физической морды лиТСа, три номера (на самом деле четыре, один в планшете, он есть, но только для экстренных случаев, когда оба телефона дома остаются, поэтому я его не считаю) телефона используется. А ещё у людей бывают стационарные телефоны.

Это как? В массиве? У меня вот, физической морды лиТСа, три номера (на самом деле четыре, один в планшете, он есть, но только для экстренных случаев, когда оба телефона дома остаются, поэтому я его не считаю) телефона используется. А ещё у людей бывают стационарные телефоны.

в массиве объектов в jsonb, например, да

это как join, только ты его руками не пишешь и не думаешь, что твои данные всё равно в отдельную toast-таблицу лягут ;)

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

Таблица контактс: ключ, в который помимо всего прочего входит тип контакта: почта, телефон, трещалка (имя протокола, как идентификатор); собственно, сам контакт. Не вижу противоречий и сложностей в использовании.

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

это я по вчерашнему собеседнику)

Таблица контактс: ключ, в который помимо всего прочего входит тип контакта: почта, телефон, трещалка (имя протокола, как идентификатор); собственно, сам контакт. Не вижу противоречий и сложностей в использовании.

плюсую ничего сложного нет, просто вчера было обсуждение что телефон выделен в отдельную наследуемую таблицу я же хотел от этого предостеречь)

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

Ну и что? В RDBMS сущности моделируются таблицами, т.е. это нормально. INHERITS как-то не очень согласуется с реляционной теорией, кстати.

я про то что телефон это все таки атрибут сущности а не сущность)

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

но клипать под каждый чих отдельные сущности это все таки неверно)

лучше такие данные хранить в jsonb

или в отдельных колонках если они частые

лучше такие данные хранить в jsonb

А я думаю, что не лучше. Я ранее уже приводил аргументы, почему так.

или в отдельных колонках если они частые

А это уж вовсе похоже на нарушение 1NF...

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

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

У меня дурацкий вопрос, уважаемые коллеги. Есть 9.2 (не пинайте, в наследство досталось, процедура обновления в производстве) от меня требуется выборка ТОП-10 самых нагруженных таблиц по обращениям к ним. Я правильно понимаю, что именно количество обращений к таблице выбрать проблематично, или сижу в глазки развлекаюсь, глядючи в документацию? Т.е. pg_stat_user_tables содержит количество записей в различных разрезах. А есть ли информация по количеству обращений к таблице?

я про то что телефон это все таки атрибут сущности а не сущность)

Это связь многие-ко-многим.

у Ярослава телефоны реализованы через inherist таблицы, там думаю связь получается 1 к 1

точнее даже так к одной организации только 1 телефон можно прицепить, но по одному номеру телефона может быть много разных организаций

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

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

Может, покажете (хотя бы приблизительно) свою модель (а то я как-то уже потерял нить, извините)?

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

Нет. Обычные цели нормализации.

у Ярослава телефоны реализованы через inherist таблицы, там думаю связь получается 1 к 1

Вообще нет, это не у меня. ;)

Народ, что, никто не знает, как получить количество обращений к таблице? Или я хочу странного?

pg_stat_all_tables

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

ЗЫ. Пг - 9.2. Тяжёлое наследство, которое я разгребаю.

seq_scan+idx_scan?

Ага

Тогда общее количество получается: seq_scan+idx_scan+n_tup_ins+n_tup_del+n_tup_upd?

Потому что базюлька - OLTP, т.е. и чтение, и запись...

зачем ты их хочешь всё схлопнуть в некия "обращения"

о чем они тебе расскажут

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

Потому что базюлька - OLTP, т.е. и чтение, и запись...

Ну вот вроде и в 9.2 там что-то есть: https://www.postgresql.org/docs/9.2/static/monitoring-stats.html#PG-STAT-ALL-TABLES-VIEW И далее по тексту, кстати (pg_stat_all_indexes, pg_statio_*).

зачем ты их хочешь всё схлопнуть в некия "обращения"

Команда сверху: таблицы, к которым наибольшее количество обращений.

А для меня без расшифровки - это именно общее количество.

Команда сверху: таблицы, к которым наибольшее количество обращений.

ну так можно быть не тупым роботом и предоставить топ в разных срезах

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

Мне надо сегодня дать информацию. pg_stat_statement - перезапускать ПГ на проде мне никто не даст.

Всем привет, подскажите пожалуйста, кто сталкивался с такой ошибкой cannot execute UPDATE in a read-only transaction В МАСТЕР базе?

Тогда общее количество получается: seq_scan+idx_scan+n_tup_ins+n_tup_del+n_tup_upd?

так ты смешивешь кол-во сканов с тюплями

Всем привет, подскажите пожалуйста, кто сталкивался с такой ошибкой cannot execute UPDATE in a read-only transaction В МАСТЕР базе?

подключаетесь напрямую или через pgbouncer?

если считать только в тюплях, там есть цифры сколько было насканено каждым методом

Мне надо сегодня дать информацию. pg_stat_statement - перезапускать ПГ на проде мне никто не даст.

ты пойми сперва в каких попугаях хочешь посчитать

Всем привет, подскажите пожалуйста, кто сталкивался с такой ошибкой cannot execute UPDATE in a read-only transaction В МАСТЕР базе?

Дай угадаю - JAVA?

так ты смешивешь кол-во сканов с тюплями

Угу, туплю сижу. :(

Всем привет, подскажите пожалуйста, кто сталкивался с такой ошибкой cannot execute UPDATE in a read-only transaction В МАСТЕР базе?

"BEGIN TRANSACTION READ ONLY;"?

Скорее всего у него баунсер с транзакционным пулингом + SPRING. Еще это пусть посмотрит https://github.com/pgbouncer/pgbouncer/issues/224

Дай угадаю - JAVA?

не угадал, С++

подключаетесь напрямую или через pgbouncer?

pgbouncer

"BEGIN TRANSACTION READ ONLY;"?

это исключили

как минимум сразу включите session pooling и дальше разбирайтесь

show default_transaction_read_only;

это исключили

Тогда это почти наверняка связано с pgbouncer. У вас transaction pooling? А вообще, посмотрите ссылки, которые давали выше...

Тогда это почти наверняка связано с pgbouncer. У вас transaction pooling? А вообще, посмотрите ссылки, которые давали выше...

в transaction pooling

Тогда это почти наверняка связано с pgbouncer. У вас transaction pooling? А вообще, посмотрите ссылки, которые давали выше...

в ссылке указывается про Java SPRING, у меня С++

в ссылке указывается про Java SPRING, у меня С++

Ну так проблема может быть той же. А вы не пробовали включить log_statement и "отловить" проблему?

show default_transaction_read_only;

default_transaction_read_only ------------------------------- off (1 row)