notes/db/sql/postgres/docs/whatsnew.txt

18
https://www.postgresql.org/docs/release/18.0/
    https://habr.com/ru/companies/selectel/articles/951172/
PostgresProfessional - Luzanov - Whats New in PG 18 54:00 of 58:28
    https://www.youtube.com/watch?v=IWyiyzA3yvA
    ! 01:00 \dconfig+ io_*combine_limit
    ! 12:30 API for adding new Explain info 
    !   https://www.postgresql.org/docs/18/pgoverexplain.html
    ! 54:00
    !   vacuumdb --all --analyze-in-stages [--missing-stats-only pg18 only]

https://t.me/pg_guru/1029
*****
Уже завтра должна выйти новая, 18я версия PostgreSQL! Давайте посмотрим на еще одно улучшение производительности в этой версии. Это улучшение решает давнее ограничение, когда многоколоночные B-tree индексы могли эффективно использоваться только в запросах, включающих условия равенства для ведущих (крайних слева) столбцов индекса.

До PostgreSQL 18, если у вас был индекс по (region, category, date), и вы хотели выполнить запрос по category и date, не указывая region, PostgreSQL обычно прибегал к последовательному сканированию таблицы или менее эффективному сканированию индекса. Оптимизация skip scan меняет это, позволяя PostgreSQL интеллектуально "пропускать" части индекса для поиска релеватных данных, даже если ведущие столбцы пропущены в запросе.

Чтобы понять важность skip scan, давайте сначала рассмотрим, как работают традиционные многоколоночные B-tree индексы и их ограничения.

В предыдущих версиях PostgreSQL многоколоночные B-tree индексы были наиболее эффективны, когда запросы включали условия по ведущим столбцам. Структура индекса организует данные сначала по первому столбцу, затем по второму столбцу в пределах каждого значения первого столбца и так далее.

Пример:

CREATE INDEX idx_sales_region_category_date
ON sales (region, category, date);

-Этот запрос использует индекс эффективно:

SELECT * FROM sales
WHERE region = 'North' AND category = 'Electronics';

-Этот запрос не может использовать индекс эффективно (до PG18):

SELECT * FROM sales
WHERE category = 'Electronics' AND date > '2025-01-01';

Второй запрос выше традиционно требовал от PostgreSQL сканировать все записи индекса или возвращаться к последовательному сканированию таблицы, поскольку он не указывает ведущий столбец region.

Skip scan решает эту проблему, позволяя PostgreSQL эффективно ориентироваться в структуре индекса, даже если ведущие столбцы отсутствуют в запросе. Это достигается за счет идентификации различных значений в неуказанных ведущих столбцах и выполнения целевого сканирования для каждого значения.

Оптимизация skip scan наиболее эффективна когда ведущие столбцы будут с низкой кардинальностью. Т. е. Skip scan работает лучше всего, когда пропущенные ведущие столбцы имеют относительно немного уникальных значений. Оптимизация работает, по сути, выполняя отдельные сканирования индекса для каждого уникального значения в пропущенных ведущих столбцах, поэтому меньше уникальных значений означает меньше отдельных сканирований.

Хотя skip scan значительно улучшает производительность запросов во многих сценариях, важно понимать его характеристики и ограничения.

Skip scan полезен не во всех ситуациях:

❌ Ведущие столбцы с высокой кардинальностью. Когда ведущий столбец имеет слишком много уникальных значений, skip scan становится неэффективным;

❌ Большие результирующие наборы.
Когда ваш запрос возвращает большую часть таблицы, последовательное сканирование обычно быстрее.

Планировщик запросов PostgreSQL автоматически определяет, когда skip scan целесообразен, на основе статистики таблицы и оценок стоимости. Вам не нужно вручную настраивать, когда его использовать - планировщик выбирает наиболее эффективный подход для каждого запроса.

Поддерживайте актуальность статистики таблиц, чтобы обеспечить принятие планировщиком хороших решений об использовании skip scan. Свежая статистика помогает PostgreSQL точно оценивать кардинальность столбцов индекса и принимать оптимальные решения по использованию skip scan.

Ограничения

Skip scan в PostgreSQL 18 имеет определенную область применения:

📌 Работает только с индексами типа B-tree;
📌 Наиболее эффективен, когда пропущенные ведущие столбцы имеют низкую кардинальность;
📌 Требует по крайней мере одно условие равенства для последующего столбца в индексе;
📌 Преимущество в производительности уменьшается по мере роста количества уникальных значений в пропущенных столбцах.

Ждем PostgreSQL 18  с нетерпением! 😁

17
https://www.postgresql.org/about/news/postgresql-17-released-2936/
    https://www.postgresql.org/docs/17/release-17.html
https://www.postgresql.org/about/news/postgresql-17-rc1-released-2926/
    https://www.youtube.com/watch?v=peLXtGorl8A
    https://habr.com/ru/companies/postgrespro/articles/841408/
Otus - Whats New in PG 17 ru of 1:26:49
    https://www.youtube.com/watch?v=pAmFehV-ZV8

16
https://www.postgresql.org/about/news/postgresql-16-released-2715/
    https://www.opennet.ru/opennews/art.shtml?num=59758
    https://www.youtube.com/watch?v=iM-wVbhf8-E

15
https://www.postgresql.org/about/news/postgresql-15-released-2526/
    https://www.opennet.ru/opennews/art.shtml?num=57914
    https://www.linux.org.ru/news/opensource/16998959
    https://www.postgresql.org/docs/15/release-15.html
    https://www.postgresql.org/docs/15/sql-createstatistics.html
    https://www.crunchydata.com/blog/be-ready-public-schema-changes-in-postgres-15

14
https://www.postgresql.org/about/news/postgresql-14-released-2318/
    https://www.opennet.ru/opennews/art.shtml?num=55891
    https://www.linux.org.ru/news/opensource/16565136
    https://linuxiac.com/postgresql-14/

13
https://www.postgresql.org/docs/13/release-13.html
https://www.postgresql.org/about/press/presskit13/ru/
    https://www.opennet.ru/opennews/art.shtml?num=53774
    
12
https://www.postgresql.org/about/news/1976/
    https://www.opennet.ru/opennews/art.shtml?num=51604

11
https://www.postgresql.org/about/news/1894/
    http://www.opennet.ru/opennews/art.shtml?num=49462
    https://habr.com/company/postgrespro/blog/426745/
https://habr.com/company/raiffeisenbank/blog/414031/
https://habr.com/company/raiffeisenbank/blog/416187/

10
Postgres 10, Performance, and You
https://www.youtube.com/watch?v=nzDG5q5r-gY
https://habrahabr.ru/company/postgrespro/blog/352144/
https://wiki.postgresql.org/wiki/New_in_postgres_10
https://www.postgresql.org/about/news/1786/