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

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

Да у вас база битая, понимаете? И шаманить с ней можно либо если вам эта база уже не нужна, либо если у вас нет backup-а. Вы железо проверяли?

железо в смысле диски?

или вообще все в целом?

бекап есть, да

Всё в целом. Проблемы-то, хоть и куда реже, бывают и RAM, и motherboard. Т.е. причина corruption какая-то должна быть. Кстати, а вы не unsafe настройками работаете (fsync и т.п.)? Дисковая подсистема правильно настроена?

Конечно, может быть и так, что вы наткнулись на bug PostgreSQL, но сначала лучше исключить другие причины.

А какой backup у вас есть? Standby есть?

есть

Всё в целом. Проблемы-то, хоть и куда реже, бывают и RAM, и motherboard. Т.е. причина corruption какая-то должна быть. Кстати, а вы не unsafe настройками работаете (fsync и т.п.)? Дисковая подсистема правильно настроена?

нет, ни в коем случае, fsync = on

два standby, на них и перевели нагрузку, закрыв редактирование

Проверим железо, видимо придется восстанавится с бекапа

спасибо

Ну а если снять backup с какого-то из этих standby, развернуть его куда-то ещё, и проверить ваш task там?

(Если есть время и возможность, конечно.)

таск проверяли как раз до выполнения на продакшен что интересно выполнился успешно

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

Ну ладно, выполнить то, что на master-е вызывало проблемы (в последний раз это был VACUUM, если я правильно понял).

успешно прошел

Всей базы? Если да (и, например, её удаётся сдампить), действительно похоже на битое железо...

Дамп запустистили

Провет. Какой лучше способ долговременного хранения текстов в поле в базе данных?

Данные могу быть как 2 байта, так и 1мб

тип text!

очень хорошо подходит для хранения текстов

А чтобы меньше весило TOAST Юзать?

Без сарказма. Серьезный вопрос

тоаст сам включится когда 2kb превысит

Ясно. Спасибо

незачто

но TOAST иногда очень мешается. спросите пгпро — они расскажут подробности

fud тут распространяют

И каждая из строк по 20 байт? Или по 4 кб? ;) От размера таблицы же зависит...

по много) два поля Text с (потенциально) большими джсонами

просто я думал, что пг не будет делать seq scan для простого подсчета числа строк

просто я думал, что пг не будет делать seq scan для простого подсчета числа строк

Будет-будет, если существенно более "узкого" индекса нет (зависит от random_page_cost, впрочем). Кроме того, эти text и JSON-ы могут большей частью попадать в TOAST, поэтому сами tuples могут быть в среднем небольшими.

ну, веди каунт сам

просто я думал, что пг не будет делать seq scan для простого подсчета числа строк

Почему бы вам просто не посмотреть её размер (pg_relation_size, pg_table_size...)?

в каких случаях лучше использовать INHERITS таблицы и вообще насколько это нормальная правктика?

Вот например у меня есть разные типы клиентов, но у них всех всегда есть телефон, имя и ИНН остальное отличается по типу клиента

Думаю создать таблицу и наследуемые таблицы с дополнительными полями

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

Идеально то, что не придется искать по ИНН во всех таблицах

Думаю создать таблицу и наследуемые таблицы с дополнительными полями

Лучше не думайте, IMHO. Наследование в PostgreSQL полезно в основом для партиционирования, а для моделирования плохо подходит.

Лучше не думайте, IMHO. Наследование в PostgreSQL полезно в основом для партиционирования, а для моделирования плохо подходит.

ясно, тогда не буду думать :)

ясно, тогда не буду думать :)

Конкретнее: https://www.postgresql.org/docs/current/static/ddl-inherit.html#DDL-INHERIT-CAVEATS

https://postgrespro.ru/docs/postgrespro/10/ddl-inherit Ну я здесь читал :)

https://postgrespro.ru/docs/postgrespro/10/ddl-inherit Ну я здесь читал :)

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

Я не пробовал. Поэтому трудно говорить объективно. Поэтому и вопрос задал ?

В общем, "Возможно, в будущем эти недостатки будут исправлены..." и так уже больше десяти лет, как мне помнится. IMHO, дело тут в том, что всё это появилось "на взлёте" объектно-реляционных СУБД. Когда они "упали", на это справедливо забили.

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

Да, в основном. И сейчас их, кстати, вроде бы делают для другой цели —- полноценного партиционирования. Так что, может быть, мы увидим их и в INHERITANCE (впрочем, я эти thread-ы почти не читал).

Ну я секционирование не могу использовать в 90% случаев потому, что FK не работают

Трудно представить БД без них

Да, в основном. И сейчас их, кстати, вроде бы делают для другой цели —- полноценного партиционирования. Так что, может быть, мы увидим их и в INHERITANCE (впрочем, я эти thread-ы почти не читал).

нет, не делают

так, кто тут жаждал подробностей про компрессию в InnoDB? я нашёл немного времени: http://telegra.ph/Sravnenie-arhitektury-szhatiya-dannyh-v-InnoDB-i-PgPro-Enterprise-03-23

Ой а что тут у нас говорят! https://www.percona.com/blog/2017/11/20/innodb-page-compression/ Скопировать дырявый mysql файл дело всего 52 минут на ссд. Очень инновационный подход к сговору с производителями железа. То есть я правильно понимаю что нельзя так просто взять и скопировать компрессированн базенку мускула на другой сервер по scp? Компрессия то в таком случае в тыкву превращается, я правильно понимаю?

делают поддержку пк когда партишон кей входит в него. типа синтакс шугар

Ой а что тут у нас говорят! https://www.percona.com/blog/2017/11/20/innodb-page-compression/ Скопировать дырявый mysql файл дело всего 52 минут на ссд. Очень инновационный подход к сговору с производителями железа. То есть я правильно понимаю что нельзя так просто взять и скопировать компрессированн базенку мускула на другой сервер по scp? Компрессия то в таком случае в тыкву превращается, я правильно понимаю?

а это как раз про page compression! как раз тот, который никто не использует!

Ой а что тут у нас говорят! https://www.percona.com/blog/2017/11/20/innodb-page-compression/ Скопировать дырявый mysql файл дело всего 52 минут на ссд. Очень инновационный подход к сговору с производителями железа. То есть я правильно понимаю что нельзя так просто взять и скопировать компрессированн базенку мускула на другой сервер по scp? Компрессия то в таком случае в тыкву превращается, я правильно понимаю?

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

Ой а что тут у нас говорят! https://www.percona.com/blog/2017/11/20/innodb-page-compression/ Скопировать дырявый mysql файл дело всего 52 минут на ссд. Очень инновационный подход к сговору с производителями железа. То есть я правильно понимаю что нельзя так просто взять и скопировать компрессированн базенку мускула на другой сервер по scp? Компрессия то в таком случае в тыкву превращается, я правильно понимаю?

Речь в сравнении не про page-commpressor

А чой то мы такие грубые?

а чо вы у вас споры такие беззубые

я с чуваками из facebook обсуждал table compression против page compression. но это потянет на ещё один блог пост

делают поддержку пк когда партишон кей входит в него. типа синтакс шугар

А, значит только в некоторых частных случаях... Ну, хотя бы что-то.

нет, на самом деле, для "обычных пользователей", у которых один сервер-серверочек, page compression — очень даже вариант. примерно как pgpro enterprise. а вот если в масштабе, то только table compression

у нас к сожалению в постгресе люди ещё не различают энкодинг от компрессии

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

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

Я же правильно понимаю значение слова "компрессия" - сжатие/уменьшение объема данных без потери содержимого?

И если так, то почему его путают с энкодингом?

Я почему спрашиваю: может я что-то тоже вижу неправильно и вы мне об этом скажете

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

Или я тоже не понял

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

Ясно

Словари я думаю эффективнее байтового сжатия при ограниченном наборе значений в json

Словари я думаю эффективнее байтового сжатия при ограниченном наборе значений в json

это ортогональные вещи

Пока планирую структуру, еще вопросец тут всплыл - по эстетике ?, . Например таблица называется client_inner_sources Думаю назвать связанное поле в другой таблице client_inner_source_id Но вроде как-то длинно...

но zson например такой классный энкодинг делает, что на реальных данных одного проекта, табличка стала жырнее

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

Пока планирую структуру, еще вопросец тут всплыл - по эстетике ?, . Например таблица называется client_inner_sources Думаю назвать связанное поле в другой таблице client_inner_source_id Но вроде как-то длинно...

Ах да. Вопрос забыл задать: Как именовать связанные поля лучше? есть рекоммендации?

Пока планирую структуру, еще вопросец тут всплыл - по эстетике ?, . Например таблица называется client_inner_sources Думаю назвать связанное поле в другой таблице client_inner_source_id Но вроде как-то длинно...

cis_id

cis_id

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

?

про системы не совсем понял

Ах да. Вопрос забыл задать: Как именовать связанные поля лучше? есть рекоммендации?

хуяк_хуяк_айди норм. это как редполитика в газете - главное чтобы везде одинаково

аааааа

понял

про системы не совсем понял

ну, вдруг баз больше одной. или таблиц

Ах да. Вопрос забыл задать: Как именовать связанные поля лучше? есть рекоммендации?

Если ключ в дочерней один, так и оставлять как в родительской табличке. Если ключей больше одного, надо добавлять в имя role name. Причем иногда можно добавлять, иногда замещать role name-ом имя родительского поля. Как удобнее. Это зависит от предметки и таблицы. Role name это роль атрибута в дочерней таблице. Например два юзера посылают письмо друг другу, оба юзера, но у одного роль отправитель, у другого получатель.

ребята а про вакансию здесь можно?

Можно

ребята а про вакансию здесь можно?

Привет, кстати.

Привет, кстати.

привет ;)

Мы (health-samur.ai) делаем медицинскую платформу на FHIR/pg/k8s/clojure/cljs и нам нужен базовый самурай (postgresql in kubernetes, logical replication, a lot of jsonb, custom pg extension). Стремление к фулстеку.

Удаленно?