вот с тем народом я бы действительно в один проект не пошел

https://ebanoe.it )

И здесь ебаненькое засветилось. Люблю его.

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

Можно пример, как many to many битовыми масками делаете? Как join-ить такое?

Можно пример, как many to many битовыми масками делаете? Как join-ить такое?

Битовые маски нужны для хранения признаков, а не для объединения таблиц

подскажите плз у меня есть 2 модели Student и Group у них связи many_to_many т.е. студент может быть в нескольких группах и группы могут содержать нескольких студентов, в студенте специально для этого держу колонку group_ids - дык мне что то говорят мол так не делают и надо мол джоин таблицу делать, только я не очень понимаю смысл такого усложнения, действительно так делают или это все от лукавого?

Нарушение 1 нормальной формы, очень плох о

дык что делать то? делать как говорят?

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

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

Потому что надо сначала учиться, потом делать. Если делаете наоборот, огреби...

Читаю про нормализацию, дык зачем тогда придумали эти hstore и jsonb- это же противоречит нормализации, такой формат главно что в него что угодно засунуть можно, там нормализацией и не пахнет даже

В общем ты прав, все это использовать в реляционной СУБД - моветон.

Потому что надо сначала учиться, потом делать. Если делаете наоборот, огреби...

Золотые слова

Читаю про нормализацию, дык зачем тогда придумали эти hstore и jsonb- это же противоречит нормализации, такой формат главно что в него что угодно засунуть можно, там нормализацией и не пахнет даже

Это можно использовать для хранения данных, обрабатываемых ВНЕ БД, на клиенте.

Битовые маски нужны для хранения признаков, а не для объединения таблиц

По факту у вас many to many отсутвует. И это болше похоже на one to many, чем many to many.

Можно пример, как many to many битовыми масками делаете? Как join-ить такое?

Связь пользователь-проект. Проект как сущность в базе отсутствует вообще - он определяется ветвлением бизнес-логики в коде и полиморфизмом классов. Но пользователь может быть в нескольких проектах сразу

Связь пользователь-проект. Проект как сущность в базе отсутствует вообще - он определяется ветвлением бизнес-логики в коде и полиморфизмом классов. Но пользователь может быть в нескольких проектах сразу

Ок, many to many так можно сделать

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

Коллеги, приветсвую. Апгрейднули постгрес с 9.4 до 10.5 на весьма нагруженной базе и теперь имеет проблемы с валовой репликацией. На мастере все ок но после некоторого времени работы происходит отваливание слейва. Wal sender и wal receiver отваливаются. В логе на primary 2018-09-09 04:50:23 MSK [5542]: [1-1] LOG: terminating walsender process due to replication timeout на реплике 2018-09-09 04:50:46 MSK [5728]: [2-1] FATAL: could not send data to WAL stream: server closed the connection unexpectedly репликация warm standby or log shipping в это время SELECT * FROM pg_stat_replication; отдаёт пустую табличку, а должен показывать статистику вал сендера, Репликация восстаналивается только после рестарта слейва. Те как будто слейв не переподключается к мастеру после сетевого сбоя. Кто-нибудь сталкивался с подобным поведением? подскажите куда копать. wal_level = 'hot_standby' master max_wal_senders 5 max_replication_slots 10 wal_keep_segments 20000 wal_sender_timeout 1min track_commit_timestamp off synchronous_standby_names vacuum_defer_cleanup_age 0 slave hot_standby on max_standby_archive_delay 1h max_standby_streaming_delay 1h wal_receiver_status_interval 10s hot_standby_feedback off wal_receiver_timeout 1min wal_retrieve_retry_interval 5s

пробовали менять hot_standby_feedback = on -> off, воспроизводится

Коллеги, приветсвую. Апгрейднули постгрес с 9.4 до 10.5 на весьма нагруженной базе и теперь имеет проблемы с валовой репликацией. На мастере все ок но после некоторого времени работы происходит отваливание слейва. Wal sender и wal receiver отваливаются. В логе на primary 2018-09-09 04:50:23 MSK [5542]: [1-1] LOG: terminating walsender process due to replication timeout на реплике 2018-09-09 04:50:46 MSK [5728]: [2-1] FATAL: could not send data to WAL stream: server closed the connection unexpectedly репликация warm standby or log shipping в это время SELECT * FROM pg_stat_replication; отдаёт пустую табличку, а должен показывать статистику вал сендера, Репликация восстаналивается только после рестарта слейва. Те как будто слейв не переподключается к мастеру после сетевого сбоя. Кто-нибудь сталкивался с подобным поведением? подскажите куда копать. wal_level = 'hot_standby' master max_wal_senders 5 max_replication_slots 10 wal_keep_segments 20000 wal_sender_timeout 1min track_commit_timestamp off synchronous_standby_names vacuum_defer_cleanup_age 0 slave hot_standby on max_standby_archive_delay 1h max_standby_streaming_delay 1h wal_receiver_status_interval 10s hot_standby_feedback off wal_receiver_timeout 1min wal_retrieve_retry_interval 5s

Странно. А в логах primary/replica что? И в запросах (по системным каталогам), связанным с репликацией? И какая именно репликация, streaming? streaming + log shipping (вдруг Вы не то имеете в виду)?

Странно. А в логах primary/replica что? И в запросах (по системным каталогам), связанным с репликацией? И какая именно репликация, streaming? streaming + log shipping (вдруг Вы не то имеете в виду)?

на primary 2018-09-09 04:50:23 MSK [5542]: [1-1] LOG: terminating walsender process due to replication timeout на реплике 2018-09-09 04:50:46 MSK [5728]: [2-1] FATAL: could not send data to WAL stream: server closed the connection unexpectedly репликация warm standby or log shipping в это время SELECT * FROM pg_stat_replication; отдаёт пустую табличку, а должен показывать статистику вал сендера,

на primary 2018-09-09 04:50:23 MSK [5542]: [1-1] LOG: terminating walsender process due to replication timeout на реплике 2018-09-09 04:50:46 MSK [5728]: [2-1] FATAL: could not send data to WAL stream: server closed the connection unexpectedly репликация warm standby or log shipping в это время SELECT * FROM pg_stat_replication; отдаёт пустую табличку, а должен показывать статистику вал сендера,

Ну а что у Вас с сетью происходит? И ещё, Вы логи "вокруг" этих сообщений посмотрите (примерно в то же время)...

сеть может сбоить, но на 9.4 не было проблем

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

И здесь ебаненькое засветилось. Люблю его.

Говно ж сэр

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

Все какое то однотипное и тупое

It happens было повеселее

Говно ж сэр

++

сеть может сбоить, но на 9.4 не было проблем

> Репликация восстаналивается только после рестарта слейва. Меня вот это удивляет. Казалось бы, у Вас что-то не так с настройками.

Настройки стабильны несколкько лет. в 10 Ничего вроде особо не поменялось судя по докам, кроме альтернативного именования wal_level

и оно работает, те вот сутки работает после ресинка. потом - бац, и сендер отваливается

на сколько я понимаю - это в приницпе допустимая ситуация, но ресивер как будто не перезапускается после этого FATAL'а

Настройки стабильны несколкько лет. в 10 Ничего вроде особо не поменялось судя по докам, кроме альтернативного именования wal_level

> Настройки стабильны несколкько лет. Ну и что? Вы никогда не видели, что всё несколько лет работает, потом что-то случается, открываешь код/настройки и поражаешься, как это вообще могло работать? ;) Т.е. ранее Вы просто могли не "нарываться" на какую-то конкретную ситуацию. Так что либо Вы нашли bug в PostgreSQL, либо с настройками (особенно учитывая "ресивер как будто не перезапускается после этого FATAL'а") у Вас что-то очень не так. Лично я ставлю на второе, а Вы? ;)

> Настройки стабильны несколкько лет. Ну и что? Вы никогда не видели, что всё несколько лет работает, потом что-то случается, открываешь код/настройки и поражаешься, как это вообще могло работать? ;) Т.е. ранее Вы просто могли не "нарываться" на какую-то конкретную ситуацию. Так что либо Вы нашли bug в PostgreSQL, либо с настройками (особенно учитывая "ресивер как будто не перезапускается после этого FATAL'а") у Вас что-то очень не так. Лично я ставлю на второе, а Вы? ;)

имел место грейд железа и переезд в другой датацент, мб дело в этом. Ок попробуем потюнить wal_sender_timeout и wal_receiver_timeout

имел место грейд железа и переезд в другой датацент, мб дело в этом. Ок попробуем потюнить wal_sender_timeout и wal_receiver_timeout

Вы, наверное, не поняли, что я Вам посоветовал — проверьте все (не default) значения настроек, связанных с репликацией. Ещё раз: неважно, как долго Вы их использовали — они могли быть "косыми" все эти годы, Вам просто везло.

Подтверждаю. Мы тоже ловили приветы в конфигах

Вы, наверное, не поняли, что я Вам посоветовал — проверьте все (не default) значения настроек, связанных с репликацией. Ещё раз: неважно, как долго Вы их использовали — они могли быть "косыми" все эти годы, Вам просто везло.

Уже. И кмк дело как раз в дефолтных значениях

master max_wal_senders 5 max_replication_slots 10 wal_keep_segments 20000 wal_sender_timeout 1min track_commit_timestamp off synchronous_standby_names vacuum_defer_cleanup_age 0 slave hot_standby on max_standby_archive_delay 1h max_standby_streaming_delay 1h wal_receiver_status_interval 10s hot_standby_feedback off wal_receiver_timeout 1min wal_retrieve_retry_interval 5s

видимо при сбое сети wal_sender_timeout - мастер убивает сендера для слейва и слейв отваливается с FATAL

предполагаю что увеличение этого значения больше чем на слейве исправит ситуацию

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

мда...

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

Есть мысли как улучшить delete в mysql innodb? Покрутил cashe , добавил памяти innodb buffer, вообщем то все настройки такие покрутил Пробовал удалять в цикле, подавая через limit и все записи сразу delete через условие с помощью join

Иди psql лучше справится?

В таблице 35 мл записей

Есть мысли как улучшить delete в mysql innodb? Покрутил cashe , добавил памяти innodb buffer, вообщем то все настройки такие покрутил Пробовал удалять в цикле, подавая через limit и все записи сразу delete через условие с помощью join

Необходимо создать копию таблицы, перенаправить всех клиентов, а затем перевести все необходимые данные с главной таблицы. После этого Вы можете с помощью truncate очисть таблицу, а затем перевести все данные на основную таблицу.

insert получается намного быстрее delete? нужно что то менять в настройках памяти?

insert получается намного быстрее delete? нужно что то менять в настройках памяти?

какое количество данных Вы пытаетесь удалить?

35мл из 40мл

дальше база будет еще больше

~200мл

Для начала Вам необходимо проверить сам запрос с помощью EXPLAIN

а я смотрел его

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

и его не обойти(

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

Значит у вас условие удаления не по ключу

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

так?

Значит у вас условие удаления не по ключу

человеку надо грохнуть 35 млн записей из 40. Я подозреваю, что подобное в любой СУБД пойдёт по черз скан всей таблицы, независимо от индексов.

Тогда для меня загадка существования индексов ))) 1000 записей - используем индекс, лям - да зачем он нужен? %)

Скорее всего планировщик намерено выбирает секскан тк большую часть таблицы обновлять. ему придется обоити каждую строку и пометить ее как дуаленную. тут особо не ускоришь. если вам позарещ нужен индексскан - попробуйте перед эксплейном сделать set enable_seqscan =off;

если у вас всгде будет 95 процентов удаляться то лучше вам делать BEGIN; CREATE new_table as select * from old_tabl where INDEX_CONDITION; DROP TABLE old_tabl; ALTER TABLE new_table RENAME to old_tabl; commit; индекс по 5% вставки будет эффективнее.

понял спасибо!

Думаю, можно партицировать таблицу и удалить партиции?

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

Это в данном случае не самое страшное.

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

Блин, DDL, запрос... Иначе не о чем говорить

Есть мысли как улучшить delete в mysql innodb? Покрутил cashe , добавил памяти innodb buffer, вообщем то все настройки такие покрутил Пробовал удалять в цикле, подавая через limit и все записи сразу delete через условие с помощью join

Еще можно выключить временно бинарное логирование и поставить innodb_flush_log_at_trx_commit=2, еще уровень изоляции выставить read committed, чтобы два раза не перечитывал во время удаления

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

Анастасия Габлеева будет жить. Поприветствуем!

Если люди упоролись и хранят всю строку как один jsonb , то чтобы его обновлять ничего кроме serializable придумать нельзя?

По идее SI (стандартный RR/RC) должен отменять такие транзакции, но я не настоящий сварщик

Если люди упоролись и хранят всю строку как один jsonb , то чтобы его обновлять ничего кроме serializable придумать нельзя?

Эээ... а как это связано?

CREATE OR REPLACE FUNCTION my_func (arg TYPE ... ) RETURNS TABLE ( field1 type, field2 type ..... ) Какая разница, в пгадмине это делать или ещё где.

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

ок, как быстро и удобно я не знаю, устраняюсь )

Эээ... а как это связано?

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

По идее SI (стандартный RR/RC) должен отменять такие транзакции, но я не настоящий сварщик

Я вот тоже, но вроде RR конфликты на запись не ловят

на RR - вторая транзакция должна быть заблокирована на чтение, пока не завершится первая. то есть, теоретически, вам подходит. а вот с RC вы не заметите конфликта, да: "кто последний записал, того и тапки"