p2.Если postres не может сделать такое же последовательное чтение only индекса, как и таблицы, то это недостаток реализации.
Во-первых, Вы так говорите, как будто кто-то это может сделать в общем случае . ;)
Например, упомянутый тут MSSQL --- в общем случае не может.

Во-вторых, выгоды в этом на практике обычно нет, т.к. надо сильно постараться заполнить индекс так, чтобы от этого был выигрыш. ;)

p2.Не скажу за mssql, но оракл умеет делать последовательное сканирование индекса достаточно давно. Вопрос всего лишь в организации листовых блоков.
Что-то я сходу не нашёл, можно ссылку? Кстати, я правильно понял, что Вы имели в виду простое последовательное чтение страниц индекса (игнорируя всякие ссылки между узлами B+-дерева)?

p2.Что значит "заполнить индекс", я не понял.
Можно вставлять в индекс по-разному, в том числе так, что в итоге листья распределяются на диске совсем не по порядку ключа.

p2.Но выгода такая же как и с таблицей - последовательное чтение блоков на неssd дает значительное преимущество.
Да это ясно, а вот как Oracle этого добивается при активно модифицируемом индексе?

p2.Листовые блоки индекса - двусвязанный список. Оракловый index full scan читает листовые блоки по этому списку и дает упорядоченные значения, а index fast full scan последовательно читает все блоки индекса мультиблочными операциями IO и дает неупорядоченные значения.
Если требуется предыдущая версия измененной другой транзакцией строки, по ней будет дополнительные обращения к области undo для деконструирования изменений. И не важно откуда получена текущая версия, индекс это или таблица.
Index fast full scan посмотрел, спасибо.
Интересно (учитывая частоту проявления преимущества перед index full scan на практике
и современное распространение SSD), стоит ли это тащить в PostgreSQL?

p2.Само по себе, полное сканирование будь то таблицы или индекса специфично для хранилищ данных, а выгода возникает, когда индекс с большой вероятность вытесняется из оперативной памяти.
Нет, подождите. ;) Почему Вы думаете, что полное сканирование --- это нормально для DWH?
Даже с кучей ad-hoc запросов при хорошем проектировании и наборе индексов его увидишь не так часто, IMHO.
И, кроме того, мне кажется, что запросов, которые вообще могут с выгодой использовать "Index fast full scan", не так уж много.
И если даже их немало в конкретной БД, то какова практическая польза?

p2.Задесятки терабайт пока слишком дорого для промышленных ssd и они обычно используются как дополнительный кеш.
Ну это кому как. ;)

p2.Кроме того, последовательное чтение физической структуры хранения можно разделить на независимые куски и обрабатывать параллельно.
Так же, как и некоторые другие стратегии чтения.

p2.Чтобы занять уверенную позицию в сегменте хранилищ от 10TB, постгресу еще много чего допиливать, помимо последовательного сканирования индексов.
Например?

zasandatorВ нелистовом уровне не присутствуют поля какие в include = экономия места.

Суха теория, мой друг, а вот практических сравнений не хватает. ;)

zasandator2. в MS-SQL есть ограничение на 900 (или 914 не помню точно) байтов какие может занимать одна строка индекса (без инклуд), в инклуд можно запихать хоть гигабайт (ну это совсем конечно, но тем не менее при желании варчар(1000) вполне себе возможно)
В PostgreSQL тоже есть аналогичное ограничение, около 1/3 страницы (обычно 2712 байт, кажется).

p2.PgSQLAnonymousПочему Вы думаете, что полное сканирование --- это нормально для DWH?"Специфично для" не является синонимом "нормально для". Если уж подменять термины, то ближе будет трактовка - "ненормально для не...".

Да не собирался я ничего подменять, просто не так понял.
А полное сканирование таблиц я время от времени видел практически во всех системах,
так что ничего специфичного для DWH в нём нет (я имею в виду именно на "больших" таблицах).

p2.Если отрицать seq index only scan, чем он отличается от sec scan таблицы. Впрочем, "увидишь не так часто" говорит о другой практике работы с теми самыми ad-hoc, у меня большинство запросов агрегировали все данные или комбинацию малоселективных плохокластеризованных атрибутов. Случайный доступ к таблицам через индексы скорее редкость.
Ну да, другая практика...
А Вы можете привести более конкретные примеры: какая предметная область, какие данные, что запрашивают?

p2.А вот проход по всему только-индексу при "хорошем проектировании и наборе индексов" достаточно эффективно сокращал количество физических чтений.
Так в этом и вопрос: в каких случаях и насколько index fast full scan эффективнее index only scan-а (который в PostgreSQL уже есть)?

p2.Какие у вас системы хранения с ssd используются под postgres, какой объем ssd и какова стоимость?
Не помню точно, извините. Кажется, всего-то 2--4 Тб, а уж стоимость я совсем забыл. ;(
Суть в том, что для DWH под PostgreSQL можно использовать сколько нужно SSD/RAM,
и, в итоге, возможно, получить более производительную (чем Oracle) систему за меньшие деньги. ;)

p2.PgSQLAnonymousТак же, как и некоторые другие стратегии чтения.О каких именно стратегиях идет речь?

Об index scan-е, bitmap index scan-е, некоторых join-ах... да и вообще, многие операции могут обрабатываться параллельно.

p2.PgSQLAnonymousНапример?Стоит ли здесь сравнивать бесплатный продукт с давно пасущимися на рынке мейнстримами типа терадаты, оракла и пр.,
Да какая разница, сколько они там пасутся на рынке (пример: COBOL) и насколько они мейнстрим (пример: PHP)?
Меня гораздо больше интересуют практические технические преимущества/недостатки.

О, кстати. ;) О мейнстриме в DWH:

Since 2008 EXASOL leads the well-respected international TPC-H benchmark for analytical scenarios,
in all datavolume-based categories 100 GB, 300 GB, 1 TB, 3 TB, and 10 TB.
Notably, EXASolution holds the top position in the section "Performance" as well as "Price/Performance".

То есть, получается, сейчас это абсолютный лидер, а основана EXASOL всего-то в 2000 году, вроде. ;)

p2.когда для этого есть отдельный форум Сравнение СУБД?
Так давайте сравним там, почему бы нет?

p2.PgSQLAnonymousтак что ничего специфичного для DWH в нём нет (я имею в виду именно на "больших" таблицах).то есть, в хорошо спроектированных oltp-задачах с правильными индексами полное сканирование больших таблиц общепринятый подход.
Нет, но оно всё равно там иногда встречается .

p2.PgSQLAnonymousА Вы можете привести более конкретные примеры: какая предметная область, какие данные, что запрашивают?карты имеют множество атрибутов, но нас они интересуют как связь между персональными данными клиентов и операциями. нужно построить "куб" по месяцам, полу, возрастной группе, региону, принадлежности к целевой аудитории, контрольной группе или прочим. Так вот, пара полей номер карты+номер клиента проиндексированы и индекс в пять раз меньше таблицы карт. Поскольку пересекаются все строки, то связь клиентов на карты эффективнее решается полным сканированием индекса и хеш-джоином. Полное сканирование выполняется за 1000 многоблочных iops с последовательным доступом - 3 секунды. Поблочный случайный iops в три раза дешевле многоблочного, но их 20000 - имеем 20 секунд. Чтение исходной таблицы - 15 секунд.
Структуру я примерно понял, но это похоже на OLAP, IMHO (тогда где же агрегированные значения?).
Т.е. 3 секунды --- это fast full scan того же индекса, который index only scan проходит за 20 секунд, я правильно понял?

p2.В случае полистового прохода index scan эффективно поделить на равноценные части не заглянув в данные не получится.
Почему не получится? Для этого можно использовать гистограмму из статистики, например.