PostgreSQL ltree-vs tree module vs integer / string массивы или путь с разделителями строк

Как вы знаете, есть модуль для PostgreSQL под названием ltree. Также у вас есть возможность использовать тип массива для целых чисел (*1, см. комментарий ниже), который в этом тесте показывает, что на самом деле выполняется немного медленнее с рекурсивными запросами, по сравнению с ltree - за исключением индексирования строк (*2, см. комментарий ниже).

Я не слишком уверен в достоверности этих testresults, хотя.

мой самый большой вопрос здесь на самом деле о относительно неизвестном, и почти недокументированный модуль дерева. Описал здесь (где также можно найти документацию!!) as:

поддержка типов иерархических данных (вид лексикографических деревьев), следует перейти к contrib / tree, ожидая из-за отсутствия надлежащего документация.

после прочтения документации я немного запутался в том, должен ли я основывать свое большое приложение (CMS, где все будет храниться в иерархической древовидной структуре-не только контент, но и файлы и т. д., Поэтому вы можете увидеть, что это быстро масштабируется) вокруг ltree, нормальный материализованный путь (перечисление пути) с разделенной строкой или целочисленным массивом в качестве пути - или если относительно неизвестный "древовидный" модуль теоретически должен быть более быстрым, более масштабируемым и лучшим решением из двух.

Я уже проанализировал различные модели древовидной структуры и из-за производительности запросов, масштабируемости и переупорядочивания узлов и поддеревья, являющиеся моими основными требованиями, я смог исключить списки смежности (рекурсивный CTE не решит производительность, поскольку дерево масштабируется огромным), вложенные наборы / интервалы (не достаточно быстро в некоторых запросах, учитывая его недостатки при манупуляции дерева), таблицы закрытия (ужасно при масштабировании больших в сложных деревьях-не полезно для такого большого проекта, как мой) и т. д. и решил пойти с материализованным путем, который очень быстр для операций чтения и позволяет легко перемещать поддеревья и узлы вокруг hiearchy. Таким образом, речь идет только о лучшей из предложенных реализаций для материализованного пути.

Мне особенно любопытно услышать ваши теории или опыт работы с "деревом" в PostgreSQL.