Спасибо за комментарий! Интересная статья, в дополнение можно посмотреть выступления спикеров на форумах, перед написанием статьи увидел для себя несколько интересных в данном направлении.
Спасибо за комментарий! Действительно, USING — важная часть при работе с другими типами индексов, вроде GIN или GiST. В этой статье решил сфокусироваться на B-tree и правиле ESR, но вы правы — хотя бы краткое упоминание USING было бы уместно. Возьму на заметку для следующего материала!
Вы, кажется, несколько переоцениваете формат статьи. Это практический материал — не технический стандарт и не академическая диссертация. ESR раскрыт в контексте задач, с которыми сталкиваются разработчики в реальных проектах, а не в рамках лабораторной работы на тему "распиши каждую букву".
Заявленная цель — показать, как порядок колонок в индексе влияет на производительность. Это показано. Конкретные значения, планы, замеры — всё на месте. Если вы ожидали чего-то другого — возможно, у вас были другие ожидания, а не у статьи другие цели.
И, честно говоря, разбирать "когда эмпирика не работает" — это уже задача читателя, если он претендует на уровень выше среднего. Материал и так даёт больше, чем большинство туторсов.
Так что если вы не нашли здесь то, что хотели — вполне возможно, вам просто не сюда)
Спасибо за замечание! Действительно, в финальном запросе используются равенства по (sender_id, payment_type) и диапазон по transaction_date, а явной сортировки (ORDER BY) в SQL-запросе нет.
Однако правило ESR (Equality → Sort → Range) применяется не к самому синтаксису запроса, а к логике построения составного B-tree индекса.
Под Sort здесь понимаются не только поля, указанные в ORDER BY, а вообще колонки, по которым может быть необходим упорядоченный обход — например, для работы с диапазонами или оптимизации последовательного доступа. Это особенно актуально, когда такие поля используются для отчетов или фильтров по времени.
В нашем случае порядок (sender_id, payment_type, transaction_date) соответствует схеме E → E → R (два равенства и один диапазон), что полностью соответствует ESR и позволяет PostgreSQL эффективно "обрезать" лишние страницы в глубине индекса при чтении.
Сортировку (ORDER BY) при желании можно добавить — и этот же индекс сработает корректно, потому что он уже построен в нужном порядке.
Я намеренно сосредоточился на структуре индекса, а не конкретной форме запроса, чтобы показать, в чём суть ESR и почему это работает.
Ну и финально: ESR — это общее практическое правило, применимое к широкому классу запросов, а не к одному конкретному синтаксису.
Во-первых, добрый день)
На первые два пункта я не возражаю — да, но значения также лежат.
На третий пункт прошу ещё раз прочитать мою статью: PostgreSQL не покажет и не напишет, какие поля он отсеял, а какие нет.
Четвёртый пункт будет следствием из других. Я не отрицаю селективность, а лишь дополняю её, причём с примером.
Добра вам!
Ваши ожидания — это ваши ожидания. ;)
Это уже третий ответ - и, пожалуй, последний.)
Спасибо за комментарий!
Интересная статья, в дополнение можно посмотреть выступления спикеров на форумах, перед написанием статьи увидел для себя несколько интересных в данном направлении.
Тема оптимизации сама по себе бесконечная)
Если вы ожидали формального анализа с доказательствами на уровне оптимизатора — это скорее вопрос не к статье, а к вашим ожиданиям от неё.
https://github.com/postgres/postgres/tree/master/src/backend/access/nbtree - прошу)
Спасибо за комментарий!
Действительно,
USING— важная часть при работе с другими типами индексов, вроде GIN или GiST. В этой статье решил сфокусироваться на B-tree и правиле ESR, но вы правы — хотя бы краткое упоминаниеUSINGбыло бы уместно. Возьму на заметку для следующего материала!Вы, кажется, несколько переоцениваете формат статьи. Это практический материал — не технический стандарт и не академическая диссертация. ESR раскрыт в контексте задач, с которыми сталкиваются разработчики в реальных проектах, а не в рамках лабораторной работы на тему "распиши каждую букву".
Заявленная цель — показать, как порядок колонок в индексе влияет на производительность. Это показано. Конкретные значения, планы, замеры — всё на месте. Если вы ожидали чего-то другого — возможно, у вас были другие ожидания, а не у статьи другие цели.
И, честно говоря, разбирать "когда эмпирика не работает" — это уже задача читателя, если он претендует на уровень выше среднего. Материал и так даёт больше, чем большинство туторсов.
Так что если вы не нашли здесь то, что хотели — вполне возможно, вам просто не сюда)
Спасибо за замечание! Действительно, в финальном запросе используются равенства по
(sender_id, payment_type)и диапазон поtransaction_date, а явной сортировки (ORDER BY) в SQL-запросе нет.Однако правило ESR (Equality → Sort → Range) применяется не к самому синтаксису запроса, а к логике построения составного B-tree индекса.
Под Sort здесь понимаются не только поля, указанные в
ORDER BY, а вообще колонки, по которым может быть необходим упорядоченный обход — например, для работы с диапазонами или оптимизации последовательного доступа. Это особенно актуально, когда такие поля используются для отчетов или фильтров по времени.В нашем случае порядок
(sender_id, payment_type, transaction_date)соответствует схеме E → E → R (два равенства и один диапазон), что полностью соответствует ESR и позволяет PostgreSQL эффективно "обрезать" лишние страницы в глубине индекса при чтении.Сортировку (
ORDER BY) при желании можно добавить — и этот же индекс сработает корректно, потому что он уже построен в нужном порядке.Я намеренно сосредоточился на структуре индекса, а не конкретной форме запроса, чтобы показать, в чём суть ESR и почему это работает.
Ну и финально: ESR — это общее практическое правило, применимое к широкому классу запросов, а не к одному конкретному синтаксису.