|
Top-level
 ... особенно если таблица широкая. Если же таблица небольшая (10-20 строк, 3-5 столбцов, например, но точное число сильно зависит от, надо бы поиграться), редко меняется, но часто читается, может оказаться выгодным вообще не создавать для неё индексов – при частом чтении, она будет лежать целиком в буферном кэше, не будет вытесняться и расходы на последователное чтение будут ничтожны. 23 comments
 @strizhechenko Добавить без индексов про запас, если будут провисания — навесить индексы пост-фактум или подумать над архитектурой ещё  @strizhechenko @ale бля, я вот такое вот видел. База, в ней таблица, в таблице lob, в нем json, и вот только там данные. Программисты говорят что им нормально. @fgntfg @strizhechenko Мы на одном проекте складывали всякую вторичную инфу в JSON-колонку в постгресе. Думали, мол, ну вот сейчас со схемой определимся и отрефакторим нормально, но так и осталось по сей день кажется, лол. @strizhechenko @fgntfg Ну если таких полей много и они только там нужны, то норм, да. Но я бы такое поле тогда к конкретной другой системе прибивал в названии, типа meta_someotherservicename — чтобы было меньше соблазна его в других целях использовать. @ale @fgntfg к счастью несмотря на то, что эти строки могут синхронизироваться с двумя системами, одна строка синхронизируется строго с одной из них и это заранее известно. Поэтому для второй системы это поле используется как кэш дополнительных данных от неё же, чтобы пореже её API долбить запросами :) Чувство прекрасного у коллеги трещит, её корёжит, но та таблица по прежнему компактна :D Про #кэширование #Memoize любопытно работает. По сути это здоровенная хэш-таблица с горячими и холодными значениями, при переполнении общего размера выделенного под неё память сперва вытесняются холодные (реже читаемые). А любопытен кейс, когда для очень горячего значени набор строк не влезает в эту память — его вытесняют, оставляя эту память для более холодных значений, потому что от части строк толку нет - остальные всё равно придётся с диска заново тянуть. Хотя, наверное, клокдрифтинг между ядрами жёстко что-нибудь ломает, если где-то есть завязки на физические (таймдельты в многопроцессных системах), а не логические (чисто X было раньше Y) часы. Хэш-таблицы с шириной строго являющейся степенью двойки - это довольно ловкий ход, позволяющий вместо остатка от деления (дорого) просто дёргать младшие N-битов хэша (дёшево). Индексы по enum-полям ещё наверняка обосраться насколько выгодная тема, они ж скорее всего в int4_ops сводятся вместо text_ops.  @strizhechenko о, и енум тоже надо повторить. а то "ну это же просто, как вы это не понимаете", но задачки почему то не решаются, а как прикручивать из объяснений непонятно совсем. @strizhechenko я про свою учёбу. что енум надо повторить. а то протыкал, но в голове вообще не отложилось. Чем мне нравится #postgresql - так это тем, что он имеет стандартизированные базовые блоки для операций над данными. Никаких велосипедов! А я их видел много и выгоды от этого кастома было мало (но иногда была, когда использовалась выверенная бенчмарками хэш-функция для специфической структуры данных для большого паттерн-матчинга с кучей доп. правил, которая при росте объёмов выигрывала у компилированной гигарегулярки/схожей реализации в постгре). |
Gregory's Server
Про ширину таблиц и индексы. Я вот всё ещё не могу для себя сформулировать, насколько плохим может оказаться влияние created_at и modified_at колнок, которые частенько включают в базовую модель ORM. Обычно весь их смысл - служебный, для переливки в другие БД, витрины итд. Но чтобы по этим колонкам выгребать данные эффективно - нужны идексы по ним. Хоп - и вставка подорожала. В приложении семантику на них завязать тоже редко получается — обычно важна дата изменения конкретного столбца.
Мнения?