А альтенатива какая-то есть?

Использовать DDL для добавления характеристик, например.

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

или что вы имеете ввиду под DDL?

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

Да, это один из вариантов (зачастую, кстати, не одну, а две). Т.е. это 6NF. Другой — flat table, с отдельным NULL-аble полями под каждую характеристику.

Вообще, я бы хотел строже с этим делом, потому что за JSON нужно следить, и подчищать/генерировать. Ваш вариант хорош, но не совсем понимаю на словах как это сделать. Может есть в интернете ERD какие-то, чтобы на картинке понять как это должно выглядеть?

Хмм... а какое отношение размера базы к RAM у вас, примерно? Потому что, теоретически, даже обычную вставку hash-index должен "просаживать" так же, как UUID-ы... даже без UUID-ов. ;)

Ram 1/40 от объема примерно

Uuidы, кстати, тоже есть и тоже помогли сильно с расчетами )

Вообще, я бы хотел строже с этим делом, потому что за JSON нужно следить, и подчищать/генерировать. Ваш вариант хорош, но не совсем понимаю на словах как это сделать. Может есть в интернете ERD какие-то, чтобы на картинке понять как это должно выглядеть?

Вариант flat table очень простой — добавляете поля, когда нужны новые харакеристики, прямо в таблицу товаров: BEGIN TRANSACTION; CREATE TABLE item_характеристика(id text PRIMARY KEY, <description и/или что-то ещё, если нужно>); ... вставляете допустимые значения... ALTER TABLE items ADD COLUMN <характеристика> text REFERENCES item_характеристика; COMMIT;

Ram 1/40 от объема примерно

Странно, всё же... интересно запросы посмотреть. :) Может быть, индексированные поля — относительно длинные тексты?

Uuidы, кстати, тоже есть и тоже помогли сильно с расчетами )

Как это они помогают? ;) Кстати, если они у вас используются как PK, уже бесполезно сравнивать b-tree (для которого это худший случай) и hash (для которого все случаи такие, UUID там или нет...).

я понял, а если характеристик будет штук 100? таблица items разростется, на сколько это критично?

Как это они помогают? ;) Кстати, если они у вас используются как PK, уже бесполезно сравнивать b-tree (для которого это худший случай) и hash (для которого все случаи такие, UUID там или нет...).

раньше вместо них были нечестные uuid’ы (текстовые)

при переходе на реальные сильно место подрезалось )

varchar(36) vs uuid

я понял, а если характеристик будет штук 100? таблица items разростется, на сколько это критично?

"It depends". Т.е. около сотни обычно не без особых проблем. Но если проблемы появляются, эту модель можно и усложнить (разбиением на таблицы 1:1 просто для ускорения доступа).

я вас понял, спасибо. а можете ещё привести небольшой пример с вариантом по 6NF, тот который альтернативный для flat table? буду очень признателен

Подскажите, плиз, кто-то реализовывал партиционирование по служебному полю (дата последнего изменения)? На сколько это оправдано? Какие есть минусы? Лучше ли делать это по бизнесовым датам (которые +- не кочуют по партициям)? Допустим, версия PostgreSQL 11 Основная идея со служебным полем, чтобы в некоторых партициях были самые запрашиваемые данные, а другие разносить на медленные диски

может у кого-то нет опыта, но есть идеи почему первый или второй вариант лучше? ?

я вас понял, спасибо. а можете ещё привести небольшой пример с вариантом по 6NF, тот который альтернативный для flat table? буду очень признателен

Просто на каждую характеристику — отдельная таблица, т.е.: — таблица допустимых значений характеристики: CREATE TABLE item_характеристика_value(value text (или любой другой тип, как и в первом случае) PRIMARY KEY, <description и/или что-то ещё, если нужно>); ... вставляете допустимые значения... CREATE TABLE item_характеристика(item_id int PRIMARY KEY REFERENCES item, характеристика NOT NULL REFERENCES item_характеристика_value); При этом обычно используют соотв. VIEW-ы для доступа к характеристикам, т.к. нужен JOIN для каждой. Кроме того, обычно можно распределить характеристики по группам, т.е., например, все товары-газонокосилки будут иметь много сходных характеристик, и для оптимизации поместить их в одну таблицу: CREATE TABLE item_характеристики_газонокосилок(item_id int PRIMARY KEY REFERENCES item, характеристика1 NOT NULL REFERENCES ..., характеристика1 NOT NULL REFERENCES ..., );

Естественно, записи в таблицы для не относящихся к данному товару характеристик просто не вставляются.

Спасибо, ушел обдумывать. Вот ещё нашел, http://www.softwaregems.com.au/Documents/Student%20Resolutions/5NF%206NF%20Simple.pdf

Добрый день всем. Поделитесь пожалуйста ссылочкой на книгу Postgresql для профессионалов. Или где можно скачать эти знания

Спасибо, ушел обдумывать. Вот ещё нашел, http://www.softwaregems.com.au/Documents/Student%20Resolutions/5NF%206NF%20Simple.pdf

Да, знакомая схема (хмм... PerformanceDBA... и автора этого я откуда-то помню ;) ). Она помогает решать связанную с этим моделированием проблему: вот добавилось у вас в таблицу (flat или 6NF, неважно) какое-то новое поле... и приложение "тупо смотрит" на него и "думает" — "и что?". ;) Т.е. откуда ему знать, что это вообще характеристика? Как её показывать пользователю? Откуда брать для неё значения? (Но часть этих вопросов относится вообще к любому полю любой таблицы, поэтому, возможно, уже как-то автоматически решается вашим приложением.)

Подскажите, плиз, кто-то реализовывал партиционирование по служебному полю (дата последнего изменения)? На сколько это оправдано? Какие есть минусы? Лучше ли делать это по бизнесовым датам (которые +- не кочуют по партициям)? Допустим, версия PostgreSQL 11 Основная идея со служебным полем, чтобы в некоторых партициях были самые запрашиваемые данные, а другие разносить на медленные диски

А вы можете поподробнее про эту схему партиционирования рассказать? Оно вам, кстати, вообще зачем? ;)

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

коллеги, а как лучше восстановить работоспособность слейва? сейчас он у меня, как я понимаю ушел на далеко расстояние от мастера и лежит с такими логами cp: cannot stat '/var/lib/postgresql/9.6/main/archive/0000000100000052000000EC': No such file or directory 2018-07-24 16:04:58 MSK LOG: started streaming WAL from primary at 52/EC000000 on timeline 1 2018-07-24 16:04:58 MSK FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000052000000EC has already been removed

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

Подскажите, плиз, кто-то реализовывал партиционирование по служебному полю (дата последнего изменения)? На сколько это оправдано? Какие есть минусы? Лучше ли делать это по бизнесовым датам (которые +- не кочуют по партициям)? Допустим, версия PostgreSQL 11 Основная идея со служебным полем, чтобы в некоторых партициях были самые запрашиваемые данные, а другие разносить на медленные диски

Как бы что перемещает поле по партициям, и что оно служебное или бизнес -- не связнанные вещи.

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

Как бы что перемещает поле по партициям, и что оно служебное или бизнес -- не связнанные вещи.

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

коллеги, а как лучше восстановить работоспособность слейва? сейчас он у меня, как я понимаю ушел на далеко расстояние от мастера и лежит с такими логами cp: cannot stat '/var/lib/postgresql/9.6/main/archive/0000000100000052000000EC': No such file or directory 2018-07-24 16:04:58 MSK LOG: started streaming WAL from primary at 52/EC000000 on timeline 1 2018-07-24 16:04:58 MSK FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000052000000EC has already been removed

Переинициализировать, похоже (если этого файла у вас уже действительно нигде нет). :(

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

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

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

и условно первые три месяца держать на ssd, остальные сносить на sas

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

типа кеширования ?

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

есть еще один вопрос по партициям кто-то сравнивал производительность при вставках в партиции inheritance и нативные (PostgreSQL 10.4)?

и условно первые три месяца держать на ssd, остальные сносить на sas

То есть, сама схема статичная, по year+month? > потому что часто читаемые записи могут все равно оставаться на медленных дисках Причём тут чтение, вообще? ;) Я думал, вам для maintenance нужно...

То есть, сама схема статичная, по year+month? > потому что часто читаемые записи могут все равно оставаться на медленных дисках Причём тут чтение, вообще? ;) Я думал, вам для maintenance нужно...

да, по year+month

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

чтение при этом)

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

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

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

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

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

Ну вот если вероятность запрашивания тем меньше, чем дальше в прошлое, можно сделать "обычную" схему.

да, я тоже на ней в итоге остановился

пока только не знаю, делать на нативном партиционировании или через inheritance

потестирую оба варианта

да, я тоже на ней в итоге остановился

Да, всё равно при ваших объёмах лучше партиционировать, т.к. maintenance (индексация, VACUUM (особенно anti-wraparound) и т.п.) будет гораздо веселее, по идее. :)

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

изменения данных тоже в основном в онлайне начали пускать уже) а вот индексы concurrently идут очень долго

пока только не знаю, делать на нативном партиционировании или через inheritance

По идее, нативное a) немного быстрее сейчас b) будет намного быстрее в будущем (v11, v12), причём вам, скорее всего, это достанется без дополнительных усилий с вашей стороны. ;)

в будущем – да но до перехода на 11тую версию в проде еще не меньше, чем пол года пройдет

и перейти с inheritance в любом случае относительно просто

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

Точно нет проблем с VACUUM? Впрочем, это теперь (после улучшений в 9.6 (кажется)) "как повезёт"... и почти всегда везёт, да. ;)

да, проблемы как раз до 9.6 были

и перейти с inheritance в любом случае относительно просто

А зачем два раза делать ту же работу? ;)

с новой vm-фичей все ок

А зачем два раза делать ту же работу? ;)

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

если будет +- одно и то же, смысла мудрить нет

может декларативное все-таки быстрее окажется, как и ожидалось ?

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

А почему вы думаете, что будет "просаживаться"? Наоборот должно быть, уже сейчас! :)

ERROR: S client not available

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

может декларативное все-таки быстрее окажется, как и ожидалось ?

Сейчас (v10) декларативное мало отличается от синтаксического сахара над inheritance, но! триггеры на вставку-то написаны на C (т.е. это машинный код), и, казалось бы, должны выигрывать у plpgsql... ;)

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

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

ребятки, какую информацию о файлах вы храните в базе, например на примере картинок? я счел разумным хранить ширину/высоту в пикселях, информация о плане фото (например, для товара это "коробка", "вид спереди" и т.д.), что ещё пишете туда?

удобно будет находить товары, где нету "фото спереди" или "фото упаковки".

ну и отстойные по качеству фотки тоже можно легко найти

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

Да, это было бы странно. По крайней мере, я знаю очевидных причин.

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

всякое бывает

Может кто подскажет, делаю pg_dump базы, вылетает с ошибкой MultiXactId .... прекратил существование, видимо произошло наложение. Вменяемых манулов по данной проблеме не нашел

Всем прив,как сделать такой запрос в postgre? UPDATE table SET count = count + 1 WHERE id = '1234';

Всем прив,как сделать такой запрос в postgre? UPDATE table SET count = count + 1 WHERE id = '1234';

Так и сделать)

Может кто подскажет, делаю pg_dump базы, вылетает с ошибкой MultiXactId .... прекратил существование, видимо произошло наложение. Вменяемых манулов по данной проблеме не нашел

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

всякое бывает

Это да... я, кстати, читал по диагонали threads (в -hackers), связанные с разработкой partitioning в v11, и у меня сложилось впечатление, что как-то там всё с первого раза не очень гладко получилось. :( Потом стали исправлять, естественно, но чем кончилось, не знаю — не следил.

Так и сделать)

У меня не тот формат стоял, но теперь уже немогу єво сменить:/

написано ж using

ну или count = count::integer+1

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

Так пересоздать таблицу то как? Дропнуть её не могу

ну или count = count::integer+1

Спасибо

Так пересоздать таблицу то как? Дропнуть её не могу

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

Так пересоздать таблицу то как? Дропнуть её не могу

Если не прокатит значит и тебе не повезло. Суть в том, что этот айди транзакции - системные данные, они в select не попадают. создаёшь вторую таблицу myTable2 с точно такой же схемой, делаешь insert into myTable2 select * from myTable1 дальше truncate myTable1 (не смотрит данные вообще, просто грохает к херам, так что ей тоже пофиг на кривую транзакцию) потом дропаешь спокойно пустую старую таблицу, новую переименовываешь. Сразу предупреждаю - столкнёшься с жопой в виде перенатягивания ручками всех внешних ключей на новую таблицу.

Я так делал. Но чел как-то ещё по хитрому один решил, я на форуме находил обьсуждение древнее. Сейчас попробую ещё раз откопать

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

Vacuum freeze даёт ошибку - не удалось открыть файл pg_clog/0A85, no such file or directory

Если не прокатит значит и тебе не повезло. Суть в том, что этот айди транзакции - системные данные, они в select не попадают. создаёшь вторую таблицу myTable2 с точно такой же схемой, делаешь insert into myTable2 select * from myTable1 дальше truncate myTable1 (не смотрит данные вообще, просто грохает к херам, так что ей тоже пофиг на кривую транзакцию) потом дропаешь спокойно пустую старую таблицу, новую переименовываешь. Сразу предупреждаю - столкнёшься с жопой в виде перенатягивания ручками всех внешних ключей на новую таблицу.

Так это же какой-то (известный) bug, нет? Т.е. "чистый" (самый надёжный) способ — добиться того, чтобы получился dump (любым способом), потом обновить PostgreSQL, перенициализировать кластер и залить дамп. :(

Так это же какой-то (известный) bug, нет? Т.е. "чистый" (самый надёжный) способ — добиться того, чтобы получился dump (любым способом), потом обновить PostgreSQL, перенициализировать кластер и залить дамп. :(

https://www.postgresql.org/message-id/flat/CA%2BMJ4cRdt__yBCGhz2pqhAZ%2B1WLRTKZ-afJi0ZPBT-ti-YUVtw%40mail.gmail.comвот вроде та тема. Да, они там до чего-то докопались, но я уже не помню и это не мой кейс был

Vacuum freeze даёт ошибку - не удалось открыть файл pg_clog/0A85, no such file or directory

ну это у тебя видать кто-то кусок базы отъел

Демоны

Если не прокатит значит и тебе не повезло. Суть в том, что этот айди транзакции - системные данные, они в select не попадают. создаёшь вторую таблицу myTable2 с точно такой же схемой, делаешь insert into myTable2 select * from myTable1 дальше truncate myTable1 (не смотрит данные вообще, просто грохает к херам, так что ей тоже пофиг на кривую транзакцию) потом дропаешь спокойно пустую старую таблицу, новую переименовываешь. Сразу предупреждаю - столкнёшься с жопой в виде перенатягивания ручками всех внешних ключей на новую таблицу.

Так сама таблица-то пустая (в аналогичной базе 1с эта таблица тоже пустая)

Vacuum freeze даёт ошибку - не удалось открыть файл pg_clog/0A85, no such file or directory

Хмм... похоже на что-то другое (но я точно не помню). Можете попробовать почитать thread по ссылке.