Здравствуйте, sergey 123, Вы писали:

C>>Если записей будет существенно больше, скажем, миллиард, то и тогда я бы ожидал, что для поиска по полю a хватит составного PK по (a, b). Вообще, от индексов по (x1, … xN) мало толку при существующем индексе по (x1, …, xN, …, xM).

S1>Мало или совсем нет толка? У меня есть одна базка в которой в одной таблице(поля a,b,c,d) очень много записей и там есть составной индекс по (b,c,d), так вот при попытке искать только по b он начинает сканировать всё подряд.

А тут может быть дело в распределении значений b. Если одинаковых значений очень много, то оптимизатор решит, что использование индекса не позволит много выиграть.

Здравствуйте, sergey 123, Вы писали:

S1>Всем привет!

S1>Есть таблица t1(a integer, b integer). Есть индексы(btree) на a и b и primary key(составной) из а и b. А таблице где-то около 1000 записей.

S1>Собственно как узнать почему seq scan, а не index scan. Думаю, что потому что мало записей в таблице, но как подтвердить или опровергнуть это гипотезу?

Для такой маленькой таблицы (грубо говоря, 8…16 килобайт в зависимости от битности integer) действительно быстрее всю её всосать в память и искать тупым сканированием.

Если записей будет существенно больше, скажем, миллиард, то и тогда я бы ожидал, что для поиска по полю a хватит составного PK по (a, b). Вообще, от индексов по (x1, … xN) мало толку при существующем индексе по (x1, …, xN, …, xM).

Всем привет!

Есть таблица t1(a integer, b integer). Есть индексы(btree) на a и b и primary key(составной) из а и b. А таблице где-то около 1000 записей.

Делаю:
EXPLAIN SELECT * FROM t1 WHERE a=666;
получаю:
QUERY PLAN
--------------------------------------------------------
Seq Scan on t1 (cost=0.00..5.76 rows=1 width=8)
Filter: (a = 666)

Собственно как узнать почему seq scan, а не index scan. Думаю, что потому что мало записей в таблице, но как подтвердить или опровергнуть это гипотезу?

Заранее всем спасибо.

Здравствуйте, Centaur, Вы писали:

S1>>Есть таблица t1(a integer, b integer). Есть индексы(btree) на a и b и primary key(составной) из а и b. А таблице где-то около 1000 записей.

S1>>Собственно как узнать почему seq scan, а не index scan. Думаю, что потому что мало записей в таблице, но как подтвердить или опровергнуть это гипотезу?

C>Для такой маленькой таблицы (грубо говоря, 8…16 килобайт в зависимости от битности integer) действительно быстрее всю её всосать в память и искать тупым сканированием.

Нет, ну это ведь догадка, а хотелось бы получить какое-нибудь сообщение от postgres'а c конкретной причиной почему именно не используются индексы.

C>Если записей будет существенно больше, скажем, миллиард, то и тогда я бы ожидал, что для поиска по полю a хватит составного PK по (a, b). Вообще, от индексов по (x1, … xN) мало толку при существующем индексе по (x1, …, xN, …, xM).

Мало или совсем нет толка? У меня есть одна базка в которой в одной таблице(поля a,b,c,d) очень много записей и там есть составной индекс по (b,c,d), так вот при попытке искать только по b он начинает сканировать всё подряд.