Comments 28
Интересные цифры по размеру индексов. Полезно.
Кстати если типов котов 8 штук как в примере — индекс явно будет неселективный. Тогда уже при фиксированном и неизменном количестве типов логичнее на партицирование перейти.
p.s. да-да, конечно партицирование в постгресе — то еще веселье.
Кстати если типов котов 8 штук как в примере — индекс явно будет неселективный. Тогда уже при фиксированном и неизменном количестве типов логичнее на партицирование перейти.
p.s. да-да, конечно партицирование в постгресе — то еще веселье.
Да, партицирование у нас есть, и там много интересного. Как-нибудь расскажем про это)
Всегда было интересно — что заставляет людей, работающих на PostgreSQL, использовать VARCHAR вместо TEXT?
Соблюдают стандарт?
Между ними нет разницы ни по производительности, ни по занимаемой памяти.
Разница только в декларации намерений. Используя TEXT, мы декларируем намерение хранить «длинные тексты». А используя varchar, мы декларируем намерение хранить «короткие строки». Причем разница между «длинным» и «коротким» субъективна.
Это просто дело вкуса.
Разница только в декларации намерений. Используя TEXT, мы декларируем намерение хранить «длинные тексты». А используя varchar, мы декларируем намерение хранить «короткие строки». Причем разница между «длинным» и «коротким» субъективна.
Это просто дело вкуса.
А почему не используются справочники типов (табличка с типами котов)? Со справочником легко можно добавить новый тип, лучше контроль целостности (FK), меньше избыточность данных (как в архиваторах — создается словарь (справочник), а значение заменяется краткой ссылкой — полем CAT_TYPE::smallint).
Я не эксперт в области принципов работы субд, но разве енамы не превращаются в те самые краткие ссылки?
В общем то да, но это это фиксированно 4 байта (если уж объем так важен) + enum это же фиксированная последовательность. Что вы будете делать если вам понадобился ещё один тип, которого нет в enum'е? Если нужно добавить атрибуты для типа? Если нужно просто переименовать один тип?
Если мне понадобится добавить еще один тип, то я сделаю миграцию ALTER TYPE cat_type ADD VALUE ‘some new value’;
Атрибуты для типа за 3 года эксплуатации не понадобились. А иначе мы бы сделали по-другому.
В целом лучше использовать простые вещи, когда они подходят. А сложные брать когда не подходят простые.
Атрибуты для типа за 3 года эксплуатации не понадобились. А иначе мы бы сделали по-другому.
В целом лучше использовать простые вещи, когда они подходят. А сложные брать когда не подходят простые.
Подразумевается, что список типов котов статичный. Добавлять в него новые типы не нужно.
Контроль целостности обеспечивается самим типом ENUM.
Ну а экономия за счет 2-х байтов smallint вместо 4-х байтов enum, как показал эксперимент, все равно ничего не дает.
Контроль целостности обеспечивается самим типом ENUM.
Ну а экономия за счет 2-х байтов smallint вместо 4-х байтов enum, как показал эксперимент, все равно ничего не дает.
Пардон. А в чём тогда был смысл? Просто не приняли во внимание что не будет статичным ENUM или были какие то ещё скрытые моменты?
Если уж на то пошло, то FK (ctype) на ctype_table выглядит как более приемлемое решение, так как вписать в ctype несуществующий id будет проблематично. Плюс к тому же создать новый тип в ctype_table без требуемых прав нельзя, что можно в данном контексте считать контролем целостности.
Если уж на то пошло, то FK (ctype) на ctype_table выглядит как более приемлемое решение, так как вписать в ctype несуществующий id будет проблематично. Плюс к тому же создать новый тип в ctype_table без требуемых прав нельзя, что можно в данном контексте считать контролем целостности.
Смысл перехода от varchar к enum был в том, чтобы ограничить возможные значения type. Заодно, как бонус, получить уменьшение индекса.
Это можно было бы сделать и так, как вы говорите — вынести список возможных типов в отдельную таблицу. Но такой вариант, очевидно, сложнее. Он требует дополнительных действий и на вставке нового кота (сперва нужно получить id типа по имени типа), и на чтении котов (нужно делать join).
ENUM покрывает наши потребности полностью, и делает это более простым способом. Принцип KISS.
Ну и, опять же, декларация намерений. Создавая таблицу с типами мы декларируем, что типы будут меняться — можно добавлять новые и т. д. Создавая ENUM, мы декларируем, что список типов статичен, и меняться не будет.
insert в таблицу — штатная операция. alter type — нештатная операция. То есть мы подчеркиваем, что таких операций не хотим.
Это можно было бы сделать и так, как вы говорите — вынести список возможных типов в отдельную таблицу. Но такой вариант, очевидно, сложнее. Он требует дополнительных действий и на вставке нового кота (сперва нужно получить id типа по имени типа), и на чтении котов (нужно делать join).
ENUM покрывает наши потребности полностью, и делает это более простым способом. Принцип KISS.
Ну и, опять же, декларация намерений. Создавая таблицу с типами мы декларируем, что типы будут меняться — можно добавлять новые и т. д. Создавая ENUM, мы декларируем, что список типов статичен, и меняться не будет.
insert в таблицу — штатная операция. alter type — нештатная операция. То есть мы подчеркиваем, что таких операций не хотим.
Скорее всего Постгрес выравнивает строки по 8 байт, именно поэтому уменьшение длины строки с 60 до 58 байт не дало выигрыша.
Если дополнительно уменьшить имя на 2 символа, то таблица будет упакована плотнее.
Больше интересно, отличается ли производительность при работе с таблицами (int, smallint, smallint) и (smallint, int, smallint)?
Если дополнительно уменьшить имя на 2 символа, то таблица будет упакована плотнее.
Больше интересно, отличается ли производительность при работе с таблицами (int, smallint, smallint) и (smallint, int, smallint)?
Если вы всё ещё продолжаете гладить котов, я бы не стал делать ALTER на ENUM.
В всей этой миграции несколько смущает моемнт, что у каких-то котов с более неиспользуемыми типами этот типа взяли и заменили на NULL. То есть данные вообще пропали. Может надо было их куда-то в соседнюю таблицу выгрузить? Хотя это, конечно, вопрос к бизнесу, а не к базе как таковой.
Функция pg_indexes_size показывает расход памяти суммарно по всем индексам, связанным с таблицей, а не по каждому отдельно.
SELECT relname, relpages FROM pg_class WHERE relname LIKE '...';
покажет размер (в 8КБ страницах) каждого индекса (и таблиц)
Sign up to leave a comment.
PostgreSQL. Как правильно хранить котов или история одной миграции