одному, этот индекс применится?
если первое поле, то да
А если второе то нет?
читайте выше
Другие поля (кроме первого) добавленные в композитный индекс тоже используются при запросах, но с меньшей эффективностью (по сравнению с первым полем составного индекса) https://dba.stackexchange.com/questions/6115/working-of-indexes-in-postgresql
вы не уточнили, что это касается gist.
Нет, приведенная ссылка касается b-tree индексов.
вот вам другая ссылка https://www.cybertec-postgresql.com/en/combined-indexes-vs-separate-indexes-in-postgresql/ test=# \d t_data Table "public.t_data" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- a | integer | | | b | integer | | | c | integer | | | Indexes: "idx_data" btree (a, b, c) test=# explain SELECT * FROM t_data WHERE b = 10; QUERY PLAN --------------------------------------------------- Gather (cost=1000.00..11615.43 rows=11 width=12) Workers Planned: 2 -> Parallel Seq Scan on t_data (cost=0.00..10614.33 rows=5 width=12) Filter: (b = 10)
Меня вполне устраивает "моя" ссылка, где несколько независимых тестов показывают тот результат, о котором я написал выше. К слову, такое же поведение b-tree индексов присутствует и в других РСУБД (MSSQL и Oracle, например), так что никакого открытия здесь нет.
https://www.sqlshack.com/impact-of-the-column-order-in-composite-index-sql-server/ та же картина и в ms sql. Example 4
Можно найти подтверждение тому, что и первый индекс из композита не используется, т.е. что индексы вообще тлён. Иногда эффективней table scan Но что с того, как говорится? Бывает что использует, бывает — нет. Зависит от окружения.
index seek эффективнее index scan'а- я не понимаю о чем здесь спорить?
Обсуждают сегодня