Хэш-таблицы с шириной строго являющейся степенью двойки - это довольно ловкий ход, позволяющий вместо остатка от деления (дорого) просто дёргать младшие N-битов хэша (дёшево).
Top-level
Хэш-таблицы с шириной строго являющейся степенью двойки - это довольно ловкий ход, позволяющий вместо остатка от деления (дорого) просто дёргать младшие N-битов хэша (дёшево). 7 comments
Индексы по enum-полям ещё наверняка обосраться насколько выгодная тема, они ж скорее всего в int4_ops сводятся вместо text_ops. @strizhechenko о, и енум тоже надо повторить. а то "ну это же просто, как вы это не понимаете", но задачки почему то не решаются, а как прикручивать из объяснений непонятно совсем. @strizhechenko я про свою учёбу. что енум надо повторить. а то протыкал, но в голове вообще не отложилось. Чем мне нравится #postgresql - так это тем, что он имеет стандартизированные базовые блоки для операций над данными. Никаких велосипедов! А я их видел много и выгоды от этого кастома было мало (но иногда была, когда использовалась выверенная бенчмарками хэш-функция для специфической структуры данных для большого паттерн-матчинга с кучей доп. правил, которая при росте объёмов выигрывала у компилированной гигарегулярки/схожей реализации в постгре). |
И снова к ширине строк таблиц. У меня в обоих проектах есть статусы некоторых объектов. В целом это короткие varchar, обычно до 16 символов длиной (хотя разок уткнулись, семантично ну никак не могли название придумать короче 18 символов). В python это, само собой, #Enum. Понятное дело, хочется там, где можно избавиться от TOAST'а, шоб всё было быстро и весело, все таблицы помещались в одну страницу итд, и вкатить enum'ы и в базе, 4 байта вместо 16 звучит привлекательно, а на 20 000 000 строк ещё привлекательнее, минус 76мб из веса таблицы, да ещё и дополнительная защита от дурака.
Но судя по документации они очень неюзабельны — в миграциях alter type с добавлением новых значений можно юзать, а вот почистить от неактуального - херушки (и оно как бы справедливо, в значениях-то указатели), звучит как дохерища ручной работы. Опять же, если не меняется - есть не просит.
Бля, я чувствую как во мне просыпается техлид lingualeo.
И снова к ширине строк таблиц. У меня в обоих проектах есть статусы некоторых объектов. В целом это короткие varchar, обычно до 16 символов длиной (хотя разок уткнулись, семантично ну никак не могли название придумать короче 18 символов). В python это, само собой, #Enum. Понятное дело, хочется там, где можно избавиться от TOAST'а, шоб всё было быстро и весело, все таблицы помещались в одну страницу итд, и вкатить enum'ы и в базе, 4 байта вместо 16 звучит привлекательно, а на 20 000 000 строк ещё...