Comments 9
А вот про асинхронный ввод-вывод, почитал бы тоже с удовольствием, особенно режим записи при вставке данных в табличку, да ещё и с имеющимися индексами.
Однако существуют определённые ограничения, как указано в коммите. Наиболее заметное из них заключается в том, что нельзя создавать индексы на генерируемых столбцах типа
VIRTUAL.
Крайне огорчительно. Как раз наибольший профит дают индексируемые виртуальные поля - тут тебе и индекс, и возможность извлечения значения из индексной записи без его вычисления в процессе выполнения. Особенно когда выражение вычисляемого поля - вычислительноёмкое.
А в нынешней форме это не более чем скрытое представление поверх таблицы, пусть и с прозрачной передачей индексов
Кстати, ведь поди и статистики по вычисляемым полям - тоже не существует, да?
Подскажите, пожалуйста, в чём разница между виртуальными генерируемыми столбцами и конструкцией view?
Если строить по такому значению индекс, то оно будет сохранено куда-то на диск как минимум в индексе. А значит можно воспользоваться STORED.
VIRTUAL имеет смысл для того, что на диск попадать таки не будет. По сути сахар для VIEW, чтобы какие-то часто используемые вычисляемые данные проще задействовать в запросе.
А значит можно воспользоваться STORED.
Нет. Если воспользоваться STORED и индексацией по нему, то значение выражения будет присутствовать на диске в двух экземплярах. А при индексации по VIRTUAL на диске будет только одна копия значения выражения.
VIRTUAL имеет смысл для того, что на диск попадать таки не будет. По сути сахар для VIEW, чтобы какие-то часто используемые вычисляемые данные проще задействовать в запросе.
Вот именно - в нынешней форме это сахар, о чём я и сказал выше. А разрешение индексировать по нему добавит достаточно полезный функционал, если выражение поля тяжёлое. Всё то же, что даёт STORED, но плюс индексация. Просто сравните связывание двух таблиц по вычисляемым полям для STORED и VIRTUAL... и представьте, что STORED к тому же индексированное.
Но ведь индекс всё равно не может быть виртуальным, он реален и хранится на диске. Никто не мешает создать индекс по выражению, совпадающему с выражением в вычисляемом поле VIRTUAL.
А вот тут мы натыкаемся на ограничение функциональных индексов - необходимым (хотя и не достаточным) требованием применимости индекса является его точное литеральное соответствие выражению в запросе. А с вычисляемым столбцом, который идентифицируется по правилам идентификации объектов, такой проблемы нет. Да и повторение текста выражения, особенно когда это какое-нибудь многоэтажное безобразие, тоже такое себе...
Дело в том, что я чаще использую MySQL, а там индекс по виртуальному вычисляемому полю вполне себе может строиться и использоваться. А потому на практике ощутил, что это полезная фича.
Кстати. Есть и ещё одна достаточно важная, но не реализованная штука. А именно - в принципе отсутствие возможности сокрытия такого вычисляемого (да и невычисляемого тоже) столбца. Опять же так, как это реализовано в MySQL - при обычном SELECT и в других типах запросов без указания конкретных полей скрытое поле НЕ выводится. Для его вывода/использования нужно явное указание его в списке полей. Почему важно? Ну представьте, что у вас SELECT * является источником данных контрола, или вы используете INSERT INTO table VALUES... - и меняете структуру, добавляя поле. Вперёд, начинаем переписывать все такие запросы. Понятно, что это старый косяк - но увы, штука на практике нередкая. И сильно тормозящая именно переписывание имеющегося кода на использование новой фичи.
Что нового в PostgreSQL 18? Взгляд разработчика