Comments 5
Что-то немного запутано про таблицы:
В-третьих, если вы полагаете, что указав в select только нужные столбцы для таблицы с несколькими столбцами, запрос будет выполняться быстрее из-за меньшего количества дисковых операций ввода-вывода, то это не так.
Вообще, не очень понятно, где тут в статье про строки как тип отдельного поля, а где - про строки как записи.
И заодно про Vacuum: что будет, если его запустить на материале, где много страниц, и дырки на многих сразу? Как он спрессовывает данные между страницами?
В оригинале статья называется "How Postgres Stores Rows" - т.е. речь идет про записи, а не про varchar/text.
Никак, он чистит и оптимизирует только внутри одной страницы. Вернее, если на последней не осталось данных, то он вернёт её системе, но на практике такое не случается. Для чистки места есть vacuum full, но он лочит всю таблицу.
Вообще, в самой таблице есть ряд оптимизаций. Например, при обновлении записи новые значения будут по возможности располагаются на той же странице, чтобы не перестраивать индекс. А special area собираются использовать для 64битных tid. Но это другая тема.
В-третьих, если вы полагаете, что указав в select только нужные столбцы
для таблицы с несколькими столбцами, запрос будет выполняться быстрее
из-за меньшего количества дисковых операций ввода-вывода, то это не
так.
Ну это все же не всегда так. Статья вообще не рассказывает, что происходит если кортеж (tuple) не помещается в страницу 8Кб (TOAST). Т.е. если, допустим у нас есть таблица tbl (id int, data text), то может быть прирост прозводительности, если мы выбираем только колонку id в том случае, когда данные к колонке data не помещаются в основном хранилище и выносятся в TOAST-таблицу.
Вот есть на первый взгляд неплохая статья, объясняющая этот аспект: https://hakibenita.com/sql-medium-text-performance
rikki_tikki Спасибо за хороший перевод.
В-третьих, если вы полагаете, что указав в select только нужные столбцы для таблицы с несколькими столбцами, запрос будет выполняться быстрее из-за меньшего количества дисковых операций ввода-вывода, то это не так
Не совсем так. Даже "безобидный" тип numeric, может хранить данные, который по размеру не смогут поместиться на одну табличную страницу, даже с учетом опции максимального сжатия. В результате Postgres будет создавать отдельную TOAST таблицу. В результате, если мы используем "select * from ...", вместо указания необходимых полей, мы можем получить лишние затраты на IO в части чтения TOAST таблиц
(https://postgrespro.ru/docs/postgrespro/15/storage-toast)
Если кто то хочет более подробно узнать про хранение у PostgresPro в курсе DBA2 (https://postgrespro.ru/education/courses/DBA2) есть глава "Страницы и версии строк"
Как Postgres хранит строки