Comments 50
Имхо, достаточно было сделать запрос вроде,
SELECT
pg_column_size(row(0::float, 'a'::"char")),
pg_column_size(row(0::float, 0::smallint)),
pg_column_size(row(0::float, 0::oid))чтобы предвосхитить отсутствие существенного отличия в этом синтетическом тесте. А вот в реальных условиях, когда в таблице не пара полей, а гораздо больше и их количество с перечислениями равно как и других оптимизаций тоже, то картина уже совсем другая. Представьте, что у вас помимо пола есть ещё рабочие дни недели, где "char"[] vs oid[]. И уже былая околонулевая разница переваливает за 20%. Тут всё может иметь значение и уж тем более выравнивание:
SELECT
pg_column_size(row(0::int2, 0::int8, 0::int2, 0::int8)), -- 56
pg_column_size(row(0::int8, 0::int8, 0::int2, 0::int2)) -- 44
Тогда бы не было интриги. :) А как же интриги и расследования?
Вы абсолютно правы обоим вопросам. То как можно посмотреть размер столбца, я потом и сам так посмотрел, когда увидел, что размеры таблиц совпадают. То что выигрыш может появится в массивах и во вложенных row, вы тоже правы. Но с другой стороны это довольно нетипично для enumeration оказаться в массиве.
В общем спасибо за ценный комментарий прекрасно дополняющий эту статью.
даже если бы размер поля отличался, postgresql же не колоночная БД, случайный доступ всё нивелирует (практически нет разницы прочитать 100500 раз по 1 байту или 100500 раз по 4 байта)
Разница все равно есть. Конечно, скорее всего можно пренебречь процессорным временем, сравнивается ли в регистрах 1 байт или 4 байта. Но меньше размер — меньше размер таблицы и индекса -> они лучше влазят во все уровни кэшей, их больше попадает в различные write ahead в различные кэши и т.д. Это может быть таблица читается случайным образом, но индекс то нет. Да и таблица может искаться последовательным чтением. И на это я тоже тестировал.
Согласен с тем, что разница, скорее всего, будет небольшая. Это можно увидеть на примерах с enum и varchar. Данные в varchar тоже в несколько раз больше 4 байт в enum, точно так же как 4 байтный enum больше 1 байтных данных. Но это стало понятно только после того как я задался этим вопросом и померил эмпирический. Тогда то и стало понятно точно, какой выигрыш есть и на сколько. Больше всего разница как раз в поиске последовательном чтении, при поиске по индексу (1% выборка) она небольшая, примерно 3%, но она все же есть. А теоретический рассуждать за и против, приводить доводы одни и другие можно было бы долго.
Это может быть таблица читается случайным образом, но индекс то нет.
ну вообще-то и индексы обычно читаются совсем не последовательно.
Да и таблица может искаться последовательным чтением.
может. но изменение размера одного поля на несколько байт не особо повлияет на размер таблицы.
ну вообще-то и индексы обычно читаются совсем не последовательно.
Не совсем так. Мы же говоря абстрактно про индекс имеем в виду btree, ведь так? Движение по дереву да, непоследовательно. Но потом же в конце концов попадаем в листовые страницы, а там уже последовательное чтение. :) Подробнее можете почитать здесь:
https://habr.com/ru/company/postgrespro/blog/330544/
может. но изменение размера одного поля на несколько байт не особо повлияет на размер таблицы.
Опять же, наша разница в том, что вы рассуждаете гипотетический, а у меня эмпирические данные, поэтому могу не теоретизировать опираясь на интуицию и "здравый смысл", а отсылать к конкретным данным, ради чего все это и было и сделано.
И так, sex1 это таблица enum с 4 байтными oid, sex5 таблица с varchar. Cлово "мужчина" (как наиболее часто встречаемое) 7 букв в UTF-8, т.е. 14 байт. Ну а в реальности:
=> select pg_column_size(sex) from sex1 limit 1;
pg_column_size
4
(1 row)
=> select pg_column_size(sex),sex from sex5 limit 1;
pg_column_size | sex
15 | мужчина
(1 row)
т.е. разница почти в 4 раза, столько же, сколько разница между enum и гипотетическим 1 байтовым типом данных. Поэтому можно использовать разницу между sex1 и sex5 для того, чтобы спрогнозировать выигрыш от использования 1 байтных данных. Хотя, конечно, зависимость не будет пропорциональной, но качественно можно.
Размер таблицы и индекса можете посмотреть в статье. Индексы почти не отличаются, таблицы по размерам отличаются более заметно. Но размеры таблиц я упомянул только в теоретических рассуждениях. Интересно же было время выполнения запроса. При поиске последовательном чтением разница заметна, не в разы, но визуально в десятки процентов. Кстати, только заметил, при последовательном чтении даже очевидно, что "char" немного быстрее, чем enum, хотя размеры у них одинаковые, причем разница очевидна даже с учетом погрешности измерений (высота полосок). В случае поиска по индексу разница не столь существенна, но все равно она есть и её можно оценить.
Да я согласен с вашими "не особо", "практический нет" и т.д. Просто не понимаю с чем вы спорите? Вам не нравится, что вместо гипотетических рассуждений в стиле "не особо или быть может особо" я взял и померил? И поэтому есть эмпирические данные, которые можно анализировать.
Хотя нет, зря я не проверил.
=> SELECT
-> pg_column_size(row(0::float, 'a'::"char")),
-> pg_column_size(row(0::float, 0::smallint)),
-> pg_column_size(row(0::float, 0::oid));
pg_column_size | pg_column_size | pg_column_size
----------------+----------------+----------------
33 | 34 | 36
(1 row)
Все таки так разница есть, на столько байт, сколько и должно было бы быть. А вот размеры таблиц точно равны.
Я пытался сказать, что даже без "tuple alignment" разница в размерах кортежа очень мала и такой тест в принципе теряет смысл. А с ним таблицы вообще одинаковы. Индексы не стоило сравнивать в принципе, при такой дискретности значений это не имеет никакого смысла.
И моё опасение в том, что стоит только добавить ещё одно enum/"char"/smallint-поле (то есть сделать таблицу более приближённой к реальности) и картина тут же поменяется. А значит ваши выводы работают только для синтетической ситуации, когда в таблице только один enum и не других коротких полей и тем более других enum. Вы и без того проделали хорошую работу, я думаю имеет смысл её расширить. Пусть таблица состоит не только из пола, но скажем возраста и страны происхождения. Картина довольно типичная, но в случае с 2"char" + smallint мы остаёмся в пределах 4 байт, а 2enum + smallint — это уже 12 байт (в обоих случаях учитываем tuple alignment).
Я пытался сказать, что даже без "tuple alignment" разница в размерах кортежа очень мала и такой тест в принципе теряет смысл.
Нет, не теряет, тем более в принципе. Именно благодаря тесту стало очевидно и что размеры таблиц одинаковы и что разница во времени выполнения запросов очень мала. Но больше всего меня удивило, что не смотря на все сказанное, при последовательном чтении таблиц разница между запросом по enum и "char" оказалось достаточно большой, чтобы превысить погрешность измерения. Так вас послушать, то и экспериментальная физика в принципе теряет всякий смысл. Зачем? Ведь теоретики все уже придумали. :) В общем если вы не видите смысл, это не значит что смысла нет, это значит что вы его не видите. :) Да и про индексы не понял, да значений всего три, но ведь распределение у этих значений не равновероятное, а 75%, 24%, 1%.
И моё опасение в том, что стоит только добавить ещё одно enum/"char"/smallint-поле (то есть сделать таблицу более приближённой к реальности) и картина тут же поменяется.
Да не сильно. Ведь поиск будет по индексу, а в индексе скорее всего будет только один enum. Не, конечно можно придумать всякие синтетические случаи, но думаю, это не интересно.
Пусть таблица состоит не только из пола, но скажем возраста и страны происхождения.
Категорический против. :) Пол в качестве enum это еще куда ни шло. А вот возраст… ни в какие ворота. Обычно возраст это дата. Но и то не всегда. :) У иностранцев в паспортах вполне может указан только год рождения. Или год и месяц. Потому что арабы или еще кто кочевал в это время по пустыни и не знали точную дату рождения. :) И как оформлять в таком случае дату рождения в БД это отдельный гемор, тоже знаю как минимум два способа. Все же такое, говорят, встречается (или встречалось?) только у пожилых, у молодые как правило свою точную дату рождения знают. Но возраст как enum??? Как это?
Страна происхождения, тоже. Т.е. да, бизнес логика может быть завязана на страну. Но я бы это реализовал через структуру связанных таблиц. А для того чтобы увязать все это с захардкоженной бизнес логикой с помощью enum ставил бы метки для бизнес логики.
Но суть вашего предложения я понял. Что будет, если в таблице будет несколько enum?
=> create table multisex1 (id float, sex1 sex_enum not null, sex2 sex_enum not null, sex3 sex_enum not null);
CREATE TABLE
=> create table multisex2 (id float, sex_char1 "char" not null, sex_char2 "char" not null, sex_char3 "char" not null);
CREATE TABLE
=> insert into multisex1 (id,sex1,sex2,sex3) select id,sex,sex,sex from sex1;
INSERT 0 10000000
=> insert into multisex2 (id,sex_char1,sex_char2,sex_char3) select id,sex_char,sex_char,sex_char from sex2;
INSERT 0 10000000
=> vacuum full freeze analyze multisex1, multisex2;
VACUUM
\dt+
=> \dt+
List of relations
Schema | Name | Type | Owner | Persistence | Size | Description
--------+-----------+-------+-------+-------------+--------+-------------
public | multisex1 | table | olleg | permanent | 498 MB |
public | multisex2 | table | olleg | permanent | 422 MB |
public | sex1 | table | olleg | permanent | 422 MB |
public | sex2 | table | olleg | permanent | 422 MB |
public | sex5 | table | olleg | permanent | 498 MB |Да, размер таблицы стал различаться, а в случае тремя enum (multisex1) таблица ровно такая же, как… таблица с одним varchar (sex5). А в случае с тремя "char" размер таблицы не изменился вовсе. Т.е. выравнивание там скорее всего не по столбцам, а по строкам. Мне кажется про то как размер небольших полей, которых в таблице несколько, влияет на размеры таблиц и на производительность запросов, на эту тему можно писать другую статью. :)
Что же касается собственно поиска, то тут я уже не могу придумать достаточно универсальный и интересный для исследования поиск. Все случаи уже будут синтетические. Но если кому интересно поэкспериментировать применительно к конкретно его случаю, он сможет легко адаптировать мои скрипты для своей цели.
Нет, не теряет, тем более в принципе. Именно благодаря тесту стало очевидно и что размеры таблиц одинаковы и что разница во времени выполнения запросов очень мала. Но больше всего меня удивило, что не смотря на все сказанное, при последовательном чтении таблиц разница между запросом по enum и "char" оказалось достаточно большой, чтобы превысить погрешность измерения. Так вас послушать, то и экспериментальная физика в принципе теряет всякий смысл. Зачем? Ведь теоретики все уже придумали. :) В общем если вы не видите смысл, это не значит что смысла нет, это значит что вы его не видите. :)
Вы меня читали? Я всеми руками поддержал эксперименты, только предложил перейти от идеальных тел (таблицы с одним полем), если продолжать аналогию физикой, к реальным ;) Если вы так сведущи в экспериментальных науках, то должны понимать, насколько скрупулёзно они относятся к условиям исследования. И ваше игнорирование выравнивания, которое по сути выравнивает буфера, IO операции и т.п., совершенно бессмысленно. Вы взяли миллиметровую линейку, пытаетесь ею проводить субмиллиметровые измерения и заявляете, что с вашей точки все атомарные тела одинакового размера :) И при этом всю дорогу удивляетесь:
Видимо, это как-то связанно с выравниванием данных PostgreSQL по границам «слов».
Возможно, это связано с тем, что PostgreSQL предпочитает выравнивать данные по размерам «слов».
Вы прикиньте — да, связано))
Да и про индексы не понял, да значений всего три, но ведь распределение у этих значений не равновероятное, а 75%, 24%, 1%.
Распределение здесь не причём. Если вы вооружитесь bt_page_items и get_raw_page, то увидите, что на одно значение enum приходятся за сотню физических указателей. То есть на одной странице индекса у вас всего раз 7 встретится ваш "female", занимая эдак байт 28, а все остальные >8K будут забиты tid'ами соответствующих записей. То есть колебание размера типа привело бы к колебанию размера индекса на жалкие доли процента.
Да не сильно. Ведь поиск будет по индексу, а в индексе скорее всего будет только один enum. Не, конечно можно придумать всякие синтетические случаи, но думаю, это не интересно.
По индексу мы находим только tid (у нас же не include-индекс) и с этим tid'ом вы идёте к реальной строке в таблицу. Вот вытащили 24%*10M tid'ов из индекса, как вы того хотели, и пошли с ними в страницы с данными. А в зависимости от размера кортежа они могут быть на 1000 страницах, а могут быть на 1200. Вот вам дополнительных 200 IOPS. Когда в вашем однопользовательском тесте всё болтается в shared buffers вы этого не замечаете, а в проде… вы это либо уже понимаете, либо пока не поймёте.
Пол в качестве enum это еще куда ни шло. А вот возраст… ни в какие ворота. Обычно возраст это дата. Но и то не всегда. :) У иностранцев в паспортах вполне может указан только год рождения.
По тексту упоминался smallint, в итогом счёте брался как smallint. Откуда enum? Вы совсем не читаете оппонента? Уже предвосхищаю критику, что до smallint люди не доживают :) Это раз.
Во-вторых, да какая разница? Пусть будет год рождения. Вы правда сути не видите или вам на критику надо обязательно ответить контр-критикой, чтобы не так обидно было? ;) Никогда не видели в таблицах полей с выравниванием != 4 байт? А они есть.
Т.е. да, бизнес логика может быть завязана на страну. Но я бы это реализовал через структуру связанных таблиц.
Так enum это и есть связанная таблица. Вы сами меня в это убедили))
Но суть вашего предложения я понял.
Если поняли, то зачем тратили своё и моё время на всю эту ерунду выше придираясь к каждой мелочи?)
Что будет, если в таблице будет несколько enum?
Да поставьте год рождения (int2). Могут быть любые "select * from pg_type where typlen % 4 > 0 and typalign in ('c', 's')", я приводил примеры и массивами, и со smallint и в первом же сообщении показывал как даже порядок следования исключительно числовых полей может кардинально повлиять на размеры.
Т.е. выравнивание там скорее всего не по столбцам, а по строкам.
Не "скорее всего" и не "или то, или это", а выравнивание как по столбцам (type alignment), так и по строкам (tuple alignment).
Мне кажется про то как размер небольших полей, которых в таблице несколько, влияет на размеры таблиц и на производительность запросов, на эту тему можно писать другую статью. :)
Тогда я вообще не понимаю ваш тест. Создали условия когда и enum и char выравниваются до одинаковых размеров, сравнили одинаковые размеры, из их равенства сделали вывод что enum и char эквивалентны. Если считаете, что в статью нечего добавить — я не буду настаивать. Просто хотел помочь немного с вашим контентом и вашими скиллами))
Даже не знаю, какого признания вы хотите от меня добиться. :) Я признаюсь, что я разработчик на PostgreSQL, а не разработчик PostgreSQL, а это, как вы, наверное, догадываетесь, две большие разницы. До эксперимента я не знал, что PostgreSQL выравнивает строки по машинным словам. Никогда не нужно было, да и в документации для разработчиков на PostgreSQL об этом не упоминается. Узнал я об этом только в результате эксперимента, что было для меня маленьким открытием. И это знание мне показалось полезным и интересным. И не только это, я думаю многие мои маленькие "открытия" разработчики PostgreSQL могли бы предугадать, зная всю эту кухню изнутри.
Более того, статья адресована даже не разработчикам на PostgreSQL, а в первую очередь веб разработчикам, типа тех, что в качестве enum используют внешнюю таблицу с ключом serial (и нулевым шагом у sequence) или создают таблицы из двух полей: bigserial primary key и jsonb, куда упихивают абсолютно все данные в денормализованном виде, а потом удивляются результам.
А по поводу ваших пожеланий, то я вам могу ответить примерно теми же словами, что мне ответил Том Лейн: "Если думаете, что можете сделать лучше, сделайте." :)
Даже не знаю, какого признания вы хотите от меня добиться. :)
Несколько раз говорил:
Вы и без того проделали хорошую работу, я думаю имеет смысл её расширить
Просто хотел помочь немного с вашим контентом
Обычно авторы просто апдейтят статью и все в выигрыше. А а вы пустились в какую-то демагогию, начали изобретать сегрегацию разработчиков. Странно, но дело хозяйское. Перефразиуря Лейна: "Не хотите делать лучше, не делайте" :)
Апдейтить на что? Я не вижу в этом смысла. Более того, я так и не понял, как именно вы хотите "улучшить". Таблицу с несколькими enum я еще представить себе могу, но вот запрос по всем сразу с общим индексом… Это настолько редкая и специфичная тема, что не вижу смысла придумывать какие-то общеполезные тесты, потому что там их попросту нет. Если вы сами понимаете, чего вы хотите — сделайте. Для вас адаптировать мои скрипты (или написать свои еще лучше) это плевое дело. Даже не понимаю, почему вы пускаетесь в демагогию. Кода бы пришлось напечатать гораздо меньше, чем букв, что вы уже напечатали. Или вы только умничать умеете?
Что значит "изобретать сегрегацию разработчиков"? Вы даже этого не понимаете? Разработчики на PostgreSQL пишут на SQL и plpgsql, разработчики PostgreSQL пишут на С. Первые работают с внешним интерфейсом БД, вторые лезут во внутренности. Это совершенно разные люди, с разными навыками и знаниями.
То есть на одной странице индекса у вас всего раз 7 встретится ваш "female", занимая эдак байт 28, а все остальные >8K будут забиты tid'ами соответствующих записей. То есть колебание размера типа привело бы к колебанию размера индекса на жалкие доли процента.
Да, это объясняет.
Так enum это и есть связанная таблица. Вы сами меня в это убедили))
Есть концептуальная разница. enum редактируется с помощью DDL, внешняя таблица с помощью DML. DDL это прерогатива программиста (ну или другими словами database owner), обычный юзер работает с DML и DDL используется только для временных объектов. На планете около 200 стран, причем ситуация постоянно меняется. Страны разделяются, сливаются, происходят революции и переименовываются. А еще возникают непризнанные признанные Россией республики, с которыми у нас особые отношения в том числе по правилам пересечения границы и законодательству. И сейчас наблюдаем как одна из непризнанных республик может исчезнуть. Что программистам каждый раз переписывать код в случае изменения политических раскладов? Поэтому список стран лучше сделать в виде внешней таблицы, а не enum. Чтобы сами пользователи могли его редактировать.
Вы лучше вот что расскажите, раз вы так хорошо знаете внутренности PostgreSQL. Правда интересно. Почему запросы с join (nested loops) настолько заметно медленнее, чем запросы с подзапросом? Планы же у них одинаковые. И почему хэш индекс в PostgreSQL настолько трешовый? А переписать его можете? Ведь правда, очень позорно выглядит.
Речь здесь не только про извращенцев вроде Кончиты Вурст
А вот пол «other» — это совершенно точно известный факт, что человек чувствует и записывает в документах, что он «особенный»
CREATE TYPE sex AS ENUM ('мужчина', 'женщина', 'иное');
Не иное, а другой
Иное звучит как оскорбление.
Откуда столько неприязни к людям с другим набором хромосом?
На хабре все же цивилизованное общество
Ну, во-первых, там совершенно очевидно, что по правилам русского языка будет средний пол (называть таких людей в мужском роде это жуткий сексизм), во-вторых у всех людей другой набор хромосом, чем у меня, а в-третьих "иное" и "другое" это синонимы, но "другое" это как-то не по-русский. Ничего не имею против людей с мозаицизмом по половым хромосомам, но вот любовь к Кончите Вурст не является признаком цивилизованности. Тут вы ошибаетесь.
Нету там графы "отношения", статья не про это.
Не волнуйтесь, к извращенцам я совершенно равнодушен. Кроме тех случаев, когда они пытаются меня соблазнить, а такое, к сожалению, бывает. И тех случаев когда они к технической статье пишут комментарии об их тяжелой судьбе, мол они все такие из себя "цивилизованные", а никто этого не ценит. Вот я, например, не пишу к каждой технической статье комменты, что я обычный мужчина и предпочитаю женщин. Почему вам надо обязательно громко заявить, что вы предпочитаете использовать задний проход не по назначению или вообще себе яйца отрезать? Писать об этом в интернете, ходить на "парады" и т.д. Если по каким-то причинам не хотите брать пример с нормальных людей, так берите пример людей с другими отклонениями: зоофилов, некрофилов, копрофилов. Они никакие парады не устраивают и нигде о свои пристрастия не афишируют, просто уединяются где-то со своим объектом любви и тихо радуются жизни.
Нам? Вам кажется, что Вас в комментах уже окружают
К счастью, в комментах ничего не кажется. Но озабоченных понабежало, это точно. Такое ощущение, что есть люди, которые постоянно мониторят хабр запуская запросы поисковые "sex" и "извращенцы".
Во-первых вы критикуете не статью про PostgreSQL, а какой-то столбец "любовь и неприязнь", которой в статье не было.
А во-вторых если вы "про него" имеете в виду Томаса Нойвирта (а такие слова были только про него), то про него такими словами говорить можно.
В-третих, судя по вашим комментам вы искали вовсе не PostgreSQL.
— Откуда столько неприязни к людям с другим набором хромосом? На хабре все же цивилизованное общество.
— …Любовь к Кончите Вурст не является признаком цивилизованности.
Из чего следует, что в столбце отношения к людям у Вас присутствует только неприязнь и любовь, никаких перечислений. Этот факт составил забавный контраст теме статьи.
Да нет, это только означает что лично вас в этой статье интересует только неприязнь и любовь. Причем в выдуманном вами столбце. Я же отношение к людям в никакой столбец не заношу. Но ко всяким озабоченным троллям к которые к технической статье громоздят комментарии на тему их сексуальной озабоченности я действительно испытываю неприязнь. Ибо оффтопик.
Нет, конкретный пример, кто может использовать пол other указанный в стандарте ИКАО. В контексте, почему не надо использовать boolean для пола, что чрезвычайно широко распространено.
Не хамите, сейчас вы осознанно хамите. Да, я указал, что такой пол может употребляться как к людям с генетической патологией, так и к бородатым мужикам, которые даже не евнухи, а просто извращенцы. Это надо было чтобы объяснить читателем, почему не boolean.
И для того чтобы закрыть тему вашего глубокого внутреннего мира и ваших переживаний как связанных с тем, что я назвал Томаса Нойвирта извращенцем, как и с тем, что вы так и не научились пользоватьсяe enum, я предлагаю посмотреть следующий ролик.
Не весь, но первые минута пять секунд там как раз про это.
На этом разговор закончен.
А при чем тут антипатии? :D Это вот это уже смешно. До сих пор в техническом вопросе антипатии проявляли только вы: "это я люблю, это я не люблю". Вот если бы я вас назвал извращенцем, не имея на то оснований, только подозрения, вот это да, было бы проявлений эмоций или антипатий. Потому что было бы оскорбление. А в контексте Кончиты Вурст это не было ни оскорблением, ни проявлением каких-либо эмоций. Это было техническим термином. Как бы вам объяснить. Вот если бы назвать мужчину женщиной, это да, оскорбление. А называть мужчину мужчиной, женщину женщиной, извращенца извращенцем тут нет никаких оскорблений. Это объективная характеристика человека. И использовал я её для указания типа, к кому может применяться пол other, там как бы два случая, по медицинским показаниям и извращенцы, которые сами себя так представляют.
:D Это общепринятый термин.
https://ru.wiktionary.org/wiki/извращенец
Такой тип данных как перечисление есть во многих языках программирования. Есть и у PostgreSQL. Да, остро заточенный инструмент с конкретным предназначением.
То что программировать вы пытаетесь через эмоции "это я люблю, это я не люблю", это я понял. Почему вы к enum испытываете какие-то определенные эмоции, это я уже не понял. Но может мне и не стоит понимать ваш богатый внутренний мир и какие вы эмоции испытываете, когда пытаетесь программировать?
Не знаю, экспериментальный факт. :) После pg_prewarm видел, что запросы сначала выполняются несколько более медленно, но со временем "ускоряются". Уточню, это видел я еще на 11 PostgreSQL, не знаю как сейчас. Сейчас я просто "обновил" старый эксперимент на 13 PostgreSQL и выложил в хабр.
Если так интересно, то можете сами все проверить.
А мне стыдно читать комменты, где вместо того чтобы обсуждать технические вопросы, пишут всякие подозрительные "цивилизованные" люди, которые обижаются на то, что я извращенцев называл извращенцами. Вот если бы я нормальных людей называл извращенцами, тогда бы да, это было бы оскорбление. А извращенцев называть извращенцами это констатация факта. Ну это все равно что женщину называть женственной или человека с диагнозом имбицил называть имбицилом. Ну или как еще можно охарактеризовать бородатого мужика, который надевает на себя женское платье и идет отлить в женский туалет?
Насколько я помню, в постгре есть сложности во воремя миграций енумов.
Например, если таблица использующая енум сожержит 300-400 миллионов записей, то добавление нового значения в енум приедет к пересчетку всех записей, что может минут на 10 залочить базу данных.
Было бы интересно почитать, какой из предложенных вариантов будет самым удобным и в этом аспекте.
Перечислимый тип и PostgreSQL