Привет. Есть ли в Postgres тип данных Array/List такой, что

позволял бы хранить пару млрд чисел, вставлять в середину за число операций свойственное B+-tree логарифма (т.е. этот адский Array/list бы мог лежать не в одном Tuple, а в каком угодно числе Leaf-блоков B+-tree), возвращать элемент по индексу, удалять из начала, середины, конца, по индексу, пушить в конец?

https://www.postgresql.org/message-id/4799.1214857781%40sss.pgh.pa.us

Нет. Но, вообще, основой моделирования в реляционных СУБД являются отношения (таблицы) — почему бы не использовать их? ;)

Да просто было теоретически интересно. После того, как видел в одной nosql-хранилке возможность положить не только key=value а ещё и key=[list] с описанными свойствами листа.

Есть. Называется "таблица с первичным ключом".

Хочу миллиарды списков длиной 0...многомлн элементов. Это надо будет много много таблиц фигачить.

Одну. Правда, миллиард списков средней длиной сто тысяч хотя бы элементов -- будет занимать большэ петабайта. Боюсь, ... У вас в любом случае с этим будут некоторые проблемы.

И да, покупка лицэнзий оракла среди этих проблем будет самой небольшой.

Это не делается табличкой вообще. Например вставка в середину списка длиной лям элементов. Я хочу при этом доставать элементы по индексу. Ну или я тупой чтобы придумать такой create table. Еще раз задача: списки имеют имена или 64-битные произвольные айдишники. По id списка и index я достаю элемент. Я могу вставлять в середину списка. После такой вставки, все индексы элементов после середины ползут вверх на +1.

Если у вас там реально петабайты данных -- наймите программиста толкового, право слово.

Там есть нюансы, но в общем -- умеренной сложности структура.

Так как это делается табличкой?

Фактически -- делаете аналог toast руками, с отдельными пересчётами ключевых граничных позицый.

А для тупых дайте тынц на "toast"?

https://www.postgresql.org/docs/14/storage-toast.html

Охохо. Спасибо.

1) нанимается программист с db уклоном 2)выбирается релевантная субд, не уверен что сточные бд здесь оптимальны, например.... ну или уменьшаются аппетиты.... постгря 9-ая с объёмом в районе 2Тб уже требовала тонкой настройки структуры бд и продумывания всех запросов....

Проблемы "решить задачу" нет, интерес академический.

А раз "академический" — какая структура данных даст вот это, в принципе: > списки имеют имена или 64-битные произвольные айдишники. По id списка и index я достаю элемент. Я могу вставлять в середину списка. Это O(log(N)) на вставку/поиск/удаление в худшем случае, так? Причём с требованием: > После такой вставки, все индексы элементов после середины ползут вверх на +1. Я правильно понял?

Верно. ЗНаю реализацию такого на B+-tree например.

Хмм... если последнее работает не за O(n), и ключи именно такие — то в чём трюк?

В обновлении всех страниц по пути к корню, включая корневую. Формально -- операцыя такой жэ сложности, как и прямой поиск.

Не вижу, как это может работать. Индексы каким образом меняются? Вот исходное требование: "Я могу вставлять в середину списка. После такой вставки, все индексы элементов после середины ползут вверх на +1."

В данных хранятся не индэксы как таковые, а размеры кусков. Потому для поиска -- идёт поиск BTree, в процэссе суммируются размеры. При обновлении -- меняются все страницы от изменившэйся до корневой.

Для [абстракции] массива это сработает, да. По "удалять из начала, середины, конца" я подумал, что индексы тоже могут удаляться (быть пропущены).

Ну, при жэлании можно и элемент "пропуск индэкса" добавить -- или дажэ просто поставить нужный размер.

Примерно так.