>Да. К производительности доступа это какое имеет отношение? Самое что ни

Question

>Да. К производительности доступа это какое имеет отношение? Самое что ни

на есть прямое. Поиск по индексу - это random read. Среднее время позиционирования голвки HDD ~10msec (SSD конечно сильно лучше).
Высота дерева для достаточно большой таблицы - 4..10 (зависит от размера ключа). Если индекс не влезает целиком в память, то нам придётся делать несколько random readов, что соотвествует скорости 10..100 операций с деревом с секунду. Т.е. даже на простейший точечных запросах мы получим порядка 10 TPS. Не впечатляет?
А вот если индекс влезет целиуклм в память эта скорость увеличится на несколько порядков. С SSD картиа менее пчальная, но существенные разрыв между сокростью чтения из памяти и диска всё равно имеет место быть.

> Да для maintenance (ну и для огромных таблиц, потому что иначе не получится) они нужны на самом деле!
Вот это как раз совершенно абстрактное утверждение. Что понимается под "maintenance"? Alter table, copy, vacuum, analyze, create index,...? Опять таки тут партицирование может помочь если доступ естейственным образом партицирован (работа с неким подмножеством записей).
И почему для огромных таблиц "иначе не получится"? Есть конечно случай, когда данные просто не влезают на одну машину. Но мы же говорим про локальное партицирование?

#backend #devops #pgsql #programming #russian

0

23.01.2020

1 ответов

11 просмотров

Yaroslav Schekin · Accepted Answer

> Высота дерева для достаточно большой таблицы - 4..10 (зависит от размера ключа). Вы можете показать дерево с высотой 10 (или, хотя бы, 7), в реальной таблице (это несколько "в сторону", просто в самом деле интересно)? > Если индекс не влезает целиком в память, то нам придётся делать несколько random readов, что соотвествует скорости 10..100 операций с деревом с секунду. Нет, не придётся! Не нужно сравнивать тёплое с мягким, пожалуйста. Мы сравниваем partitioned table с обычной, и если Вам в обычной таблице пришлось бы прочитать весь индекс, то и в partitioned Вам придётся прочитать все индексы всех partitions, не так ли? > Т.е. даже на простейший точечных запросах мы получим порядка 10 TPS. Не впечатляет? Нет, не впечатляет. Было бы это на самом деле так — впечатляло бы. ;) > А вот если индекс влезет целиуклм в память эта скорость увеличится на несколько порядков. Если его читать целиком — да. Вообще, давайте разберёмся, о каком (каких) конкретных случаях (классах запросов и индексов) мы говорим? > Alter table, copy, vacuum, analyze, create index,...? Да. + ATTACH/DETACH. > Опять таки тут партицирование может помочь если доступ естейственным образом партицирован (работа с неким подмножеством записей). Скажите мне, сколько autovacuums могут работать на одной таблице одновременно? А на партиционированной "таблице", у которой 20 partitions? ;) И то же самое относится к индексам, например. Сколько будет строиться индекс на первой таблице? А на второй? Что будет, если PostgreSQL "упадёт", пока строился индекс (сколько работы будет потеряно)? А как можно строить индекс на большой таблице "по частям" (к примеру, по ночам для уменьшения нагрузки)? > И почему для огромных таблиц "иначе не получится"? Потому что: https://www.postgresql.org/docs/current/limits.html relation size 32 TB

172 похожих чатов

>Да. К производительности доступа это какое имеет отношение? Самое что ни

1 ответов

Похожие вопросы