Комментарии 12
Кластеризованная таблица в постгресе уже лет 10 наверное существует, можно уже наконец сделать ее полноценной, как в нормальных субд. Тогда можно было бы ее использовать не только для статичных справочников, но и для супер эффективного merge join по отсортированным ключам для огромных таблиц.
спасибо за ваш комментарий! мне здесь нечего добавить и я с вами полностью согласен.
Когда говорят "кластеризованная таблица" — имеют ввиду таблицу, данные в которой поддерживаются в определённом физическом порядке (сам способ хранения такой, что порядок нарушиться не может). Таких таблиц в постгресе нет и пока не предвидится. Называть то, что есть в постгресе "кластеризованной таблицей"... ну, это всё-таки слишком.
Не писать ORDER BY, когда нужна сортировка — лютая дичь. Нельзя так делать, а тем более советовать делать.
Добрый день, Егор!
Спасибо за ваш комментарий!
Здесь я имею ввиду , что если таблица четко статическая (справочник) и не происходит обновление данных в ней или происходит очень нечастое контролируемое обновление (применяя CLUSTER...), то почему бы не воспользоваться физическим размещением данных в страницах в том порядке в котором нам необходимо выдать результат.
Полностью с вами согласен, если таблица обновляема часто, то без ORDER BY не обойтись.
Дело в том, что без ORDER BY порядок не гарантируется, даже если версии строк физически расположены именно так, как надо.
В случае последовательного доступа — ключевые слова для гугления: synchronized scans.
В случае индексного доступа — легко можно наступить не на тот индекс (например, построенный в обратном порядке). Ну и кроме того, при индексном доступе ORDER BY не несет никаких дополнительных расходов.
Это же азы.
да вы правы! спасибо за это уточнение! внесу корректировки в свои материалы
Позвольте здесь привести выдержку из документации относительно параметра synchronize_seqscans, отвечающий за синхронизацию обращений при последовательном сканировании больших таблиц.
В документации сказано "Когда он включён, сканирование может начаться в середине таблицы, чтобы синхронизироваться со сканированием, которое уже выполняется. По достижении конца таблицы сканирование заворачивается к началу и завершает обработку пропущенных строк. Это может привести к непредсказуемому изменению порядка строк, возвращаемых запросами, в которых отсутствует предложение ORDER BY. Когда этот параметр выключен (имеет значение off), реализуется поведение, принятое до версии 8.3, когда последовательное сканирование всегда начиналось с начала таблицы. Значение по умолчанию — on".
ООП в SQL, абалдеть…
Интересно, конечно, дойдет ли до множественного наследования, интерфейсов, статических полей и т.д.
этому всему уже не первый десяток лет, массового использования нет, и не похоже что будет
добрый день!
да именно так, действительно этому подходу не первый десяток лет в PostgreSQL и лично для меня интересно продолжение этой истории. Не люблю сравнивать, но встретившись с функционалом в другой РСУБД с конструкторами / деструкторами / свойствами / членами класса и тд на промышленном проекте - действительно был впечатлен как это можно использовать.
Спасибо!
Типы таблиц в PostgreSQL: clustered, foreign, partitioned и inherited tables