>Вы можете показать дерево с высотой 10 Строим индекс по длинным

URL-ам или ещё лучше по случайной достаточно длинной последовательности байт (например ключ шифрования). Пусть размер ключа 256 байт. Таких записей на странице поместится 32. Страница может быть наполовину пустая. Для простоты счёта скажем - 10 ключей на странице. 10^10 - это "всего" 10 миллиардов записей. Не так чтобы очень много... Но, согласен, в большинстве случаев высота дерева меньше 5. Но всё равно, если индекс с запасом не влезает в память это 2-3 случайных чтения с диска.

> Вам придётся прочитать все индексы всех partitions, не так ли?
В том то и дело что не так. Я же как раз писал что партишины нужны если доступ сегментирвоанный и мы работаем в основном с одним партишином. Остальные индексы просто не сипользуются.

> Было бы это на самом деле так — впечатляло бы. ;)
Возьмите машину с HDD, создайте key-value таблицу размером в 100 раз больше размера памяти и попытайтесь повыполнять запросы со случайным распределением ключа. Хоть select-ы, хоть update-ы. Получите как раз эти 10-ки TPS.

>Да. + ATTACH/DETACH.
Насчёт attach/detach я согласен - но это как раз второй случай, о котором я писал. Когда нас нужно большими плюшками добавлять/удалять данные.
Насчёт autovacuum - тоже Вы правы

>Да.relation size 32 TB
Для начала сроздайте табличку на 32 TB без BLOB-ов:)
И если идёт речь о дванных такого размера, то скорее всего они не влезут на машину просто по железным ограниченям (можно конечно собрать петабйтный RAID), но лучше всё таки распределить эти данные межжду несколькими машинами.

> Не так чтобы очень много... Я правильно считаю (приблизительный) размер такого индекса? > SELECT pg_size_pretty(((10.0 ^ 10) / 10) * 8192); 7629 GB Т.е. где-то 8 терабайт? Т.е. Вы встречали такие реальные таблицы? А где/почему (если не секрет)? > Но всё равно, если индекс с запасом не влезает в память это 2-3 случайных чтения с диска. Индексы как раз и предназначены для того, чтобы "не влезать в память с запасом", нет? ;) > Я же как раз писал что партишины нужны если доступ сегментирвоанный и мы работаем в основном с одним партишином Отлично! Пусть у Вас есть partitioning by date. Тогда сравнивать его индексацию стоит с обычной таблицей, индексированной по "(date, something)", и при одинаковых запросах мы работаем с какой-то частью её индекса, практически совпадающей по размеру с индексом "(date, something)" на одной partition. Где выигрыш-то? ;) А если Вы сравниваете с чем-то другим, то лучше показать конкретный пример (и объяснить, почему Вы так сравниваете), IMHO. > Получите как раз эти 10-ки TPS. Безусловно. Только какое отношение это имеет к обсуждаемой теме? > но лучше всё таки распределить эти данные межжду несколькими машинами. Лучше чем что, простите?! Если PostgreSQL на таких данных используется не "просто так" (т.е. на самом деле стоило бы взять что-то другое!), то "распределить" = "забудьте об ACID"! Или перепишите приложения (а это стоит денег). По-моему, так.