LeXa NalBat Andrey DaeronВ ПГ в индексах хранятся номера страниц, в которых когда-то были данные и он каждый раз проверяет их там наличие (когда индекс юзает). Чем меньше страниц - тем однозначно лучше, меньше проверять.В индексе хранятся номера страниц таблицы? Проверяет их наличие в таблице? Тогда выигрыша не получается, так как параметр FILLFACTOR относится к индексу, а не таблице. А в таблице строки разбросаны по страницам, конечно в общем случае, если таблица не кластеризована по этому индексу. Или я что-то не так понял?
Вот для таблиц:
FILLFACTOR
1.
2.
3.
4.
5.
The fillfactor for a table is a percentage between 10 and 100 . 100 (complete packing) is the
default. When a smaller fillfactor is specified, INSERT operations pack table pages only to the indicated
percentage; the remaining space on each page is reserved for updating rows on that page. This gives
UPDATE a chance to place the updated copy of a row on the same page as the original, which is more
efficient than placing it on a different page. For a table whose entries are never updated, complete
packing is the best choice, but in heavily updated tables smaller fillfactors are appropriate.
Про INSERT ни слова. Для UPDATE - супер, для INSERT - пофиг.
В отличие от
обычного сканирования индекса, в котором за один раз из индекса считывается только один указатель на запись, по которому потом поднимается сама запись из таблицы , bitmap scan считывает все указатели за один раз (Bitmap Index Scan), сортирует их в памяти и потом считывает записи уже в локализованном на диске порядке (Bitmap Heap Scan). Таким образом, увеличивается скорость чтения записей с диска, но ценою создания в памяти специальной структуры данных. Заметим, что производительность ORDER BY может пострадать, так как записи считываются не в том порядке, как они хранились в индексе.
Если bitmap становится очень большим, то вместо записей хранятся ссылки на страницы, которые содержат записи, удовлетворяющие запросу. Поэтому, в таком случае, необходима дополнительная проверка (Recheck), чтобы получить только требуемые записи.
(c)
Олег Бартунов и Федор Сигаев
Но че-то меня не оставляет мысль что и в самих индексах не совсем то хранится т.е. не ссылки на записи, а на страницы. Но найти ссылку не могу. По этому - это все таки ИМХО.
LeXa NalBat
Andrey Daeron LeXa NalBatНаверное файловой системе быстрее записать в середину имеющегося файла, чем добавить к файлу кусок. Зависит от ФС? Хотя наш админ сейчас сказал, что по части ФС скорость этих операций должна быть почти одинаковая.Ну мне тоже так кажется. Может быть накладные расходы? Опять же на индексы и таблицу страниц.Мне кажется, что наблюдается существенная разница в скорости. И тесты это вроде бы подтверждают. Чтобы уменьшить влияние "накладных расходов", я бы делал тест как можно проще, на таблице без индексов и т.п.
Я не уверен, что этот код отражает происходящее в СУБД. ИМХО он слишком "простой" в реальной жизни все может быть нмного по другому.
LeXa NalBat
Andrey Daeronблок в ФС 512 байтУ меня наверное 4K, судя по тому что ls показывает размер директории 4096.
Это зависит от ОС, FS и ее настроек. 512 - размер сектора. Роясь в инете - нарыл еще и 64к сектора.
LeXa NalBat
Andrey Daeron(1000*100)/512 ~200 выделиний блоков - многоватоСтолько юзер захотел данных добавить. Кстати вовсе не много - всего 100K. И смотреть ведь надо не на абсолютное время записи данных, а сравнивать скорости двух вариантов (в аллоцированный файл, и последовательное добавление) друг относительно друга.
Может есть время на СУБД тест провести? На реальных данных? Забульбенить этак 10-50кк записей, проиндексировать к примеру сначала все четные. Потом их нафиг удалить и залить заново но уже INSERT'ом. VACUUM по вкусу :) и посмотреть и время, и физический размер файлов. Он тоже очччень интерисует.
LeXa NalBat
Andrey Daeronкоорая по размерам ИМХО больше (4к штоли)Я думал, что страница в СУБД и сраница в ФС - одно и то же. Это не так?
Нет, не так. Цитата (правда про WAL, на сколько я нашел косвенные упоминания для обычных таблиц тоже самое):
Each segment is divided into pages, normally 8 kB each . Для разных FS разные размеры кластеров, для PG - ИМХО это параметр компиляции.
