|
Top-level
 => SELECT amname, amhandler FROM pg_am WHERE amtype = 'i'; На этом книжку можно закрывать и в постгресе дальше не копаться. ОКР? Ну вот треснула бы жопа сделать btreehandler и spgisthandler? 28 comments
@sattellite хз, обработчики индексных методов доступа кажутся неотъемлемой частью индекса, более того, название обработчиков однозначно ссылается на типы индексов, по крайней мере должно ссылаться :) вряд ли делалось без оглядки на оные сверху. Почитал про методы доступа, которые Index Scan, Index Only Scan, Bitmap Scan, Seq Scan. Общий вывод, который делаю - на этапе проектирования системы крайне желательно иметь представление какого рода запросы в ней будут преобладать и оптимизировать систему под них. К примеру OLAP-нагрузка с комбинированными запросами может перекашиваться в сторону Bitmap Scan, использующий несколько независимых индексов на отдельные колонки — такой системе нужно мало воркеров, но с большим work_mem. ... это позволит избегать загрубления битмапов и лишнего recheck cond, что сократит I/O. OLTP нагрузка типа часто взять одну строчку (можно даже часть) и обновить ей 1-2 поля, напротив, хорошо выиграет от покрывающих (можно прямо в индекс дублировать данные столбца, хоть они и не будут использоваться для поиска) индексов, заточенных под конкретный запрос. Вставка их будет проигрывать от каждого доп. индекса, но поиск сможет вообще не обращаться к самой таблице. И это может оказаться плюсом. ... особенно если таблица широкая. Если же таблица небольшая (10-20 строк, 3-5 столбцов, например, но точное число сильно зависит от, надо бы поиграться), редко меняется, но часто читается, может оказаться выгодным вообще не создавать для неё индексов – при частом чтении, она будет лежать целиком в буферном кэше, не будет вытесняться и расходы на последователное чтение будут ничтожны. Про ширину таблиц и индексы. Я вот всё ещё не могу для себя сформулировать, насколько плохим может оказаться влияние created_at и modified_at колнок, которые частенько включают в базовую модель ORM. Обычно весь их смысл - служебный, для переливки в другие БД, витрины итд. Но чтобы по этим колонкам выгребать данные эффективно - нужны идексы по ним. Хоп - и вставка подорожала. В приложении семантику на них завязать тоже редко получается — обычно важна дата изменения конкретного столбца. Мнения?  @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
@strizhechenko и вот самый сложный продукт с открытым кодом, в котором патчи принимаются годами, чтобы соответствовать всем нормам. И на тебе, сэкономили на символах и теперь не вписывается в общий вид. А может они с них начинали и тогда общего видения не было?