Комментарии 17
Я так и не смог понять: для чего это всё? Ну, если не считать чистой и бескорыстной любви к C?
Расширять типы Postgres под решаемую задачу. И Си я не люблю, код написан на C++.
Ок, я готов поверить что применение C++ кардинально отличает задачу от варианта с применением простого C (сделать это непросто, но я готов).
Но я по прежнему не могу понять ответ на вопрос «Зачем?». Для решения какой прикладной задачи вы ввели эти типы? И почему вам было недостаточно тех типов, которые уже есть в PostgreSQL?
Но я по прежнему не могу понять ответ на вопрос «Зачем?». Для решения какой прикладной задачи вы ввели эти типы? И почему вам было недостаточно тех типов, которые уже есть в PostgreSQL?
Для решения какой прикладной задачи вы ввели эти типы?
Там в самом начале указано в рамках Highload Cup 2018. А на PgConf.Russia рассказывали про MobilityDB.
И почему вам было недостаточно тех типов, которые уже есть в PostgreSQL?
Уменьшение размера данных. В статье указаны размеры до и после.
Очень похоже просто на рекламу — смотрите, мы так умеем. В реальных задачах практически никто не будет заморачиваться при выигрыше в частном случае в 2,6% (16 к 595Мб)
Извиняюсь, что ответил с задержкой. Хочу процитировать Томаса Эдисона:
Результаты? Ну, что ж, друг, у меня много результатов. Я знаю пятьдесят тысяч вещей, которые не будут работать.
Не запротоколировав, не узнаешь. Да выигрыш не значительный, но статья задумывалась как продолжение Создание расширений в PostgreSQL, добавив информацию про индексы.
В реальных задачах таки заморачиваются со своими типами: PostGIS, MobilityDB.
Ну, изобретение бессмысленного, в реальной жизни, велосипеда в рамках соревнований по изобретению велосипедов — не такое уж бессмысленное занятие :). А в данном случае имел место именно этот вариант, как я понял.
Спасибо за статью!
Вы в статье упоминаете про выравнивание, а сами не совсем оптимально расположили поля, если я правильно понял:
Убрал некоторые поля — но картину не должно изменить.
Ваш вариант:
Тоже самое но не фиксированные размеры в конце
Разница в 5 байт на строку.
Вы в статье упоминаете про выравнивание, а сами не совсем оптимально расположили поля, если я правильно понял:
Убрал некоторые поля — но картину не должно изменить.
Ваш вариант:
SELECT pg_column_size(row(
1::integer, --id
'email@email.ru'::varchar(100), --email
1::smallint, --fname
'sname'::varchar(100), --sname
now()::timestamp, --birth
1::smallint, --country
1::smallint, --city
1::smallint, --email_domain
now()::timestamp, --joined
'[2010-01-01 14:30, 2010-01-01 15:30]'::tsrange, --premium
'{1,2,3}'::integer[], --likes_ids
'{1,2,3}'::integer[] --likes_tss
));
168 байт
Тоже самое но не фиксированные размеры в конце
SELECT pg_column_size(row(
1::integer, --id
1::smallint, --fname
1::smallint, --country
1::smallint, --city
1::smallint, --email_domain
'{1,2,3}'::integer[], --likes_ids
'{1,2,3}'::integer[], --likes_tss
now()::timestamp, --birth
now()::timestamp, --joined
'[2010-01-01 14:30, 2010-01-01 15:30]'::tsrange, --premium
'email@email.ru'::varchar(100), --email
'sname'::varchar(100) --sname
));
163 байта
Разница в 5 байт на строку.
Номер телефона имеет вид 8(929)5481819, восьмерку можно отбросить.Если отбрасывать восьмёрку, то прощайте не-локальные номера.
Вы же в курсе что восьмерка это на самом деле +7?
В исходниках похоже есть бага.
Переменная res инициализируется значением true, а (видимо) должно быть false.
Из-за чего последующие присваивания в циклах внутри switch не имеют смысла.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширяемый Postgres