постгрессе.
И есть вот такая таблица:
CREATE TABLE some_table
(
id BIGINT PRIMARY KEY,
v1 VARCHAR,
v2 VARCHAR,
v3 varchar(21) UNIQUE NOT NULL,
v4 VARCHAR(7),
version BIGINT NOT NULL,
reference_id BIGINT NOT NULL REFERENCES physical_resource_ref,
some_id_ref BIGINT REFERENCES some_anothr_table
);
CREATE INDEX idx_some_table_l
ON some_table (v1);
CREATE INDEX idx_some_table_h
ON some_table (v2);
CREATE INDEX idx_some_table_r
ON some_table (v3);
Как видно, есть три индекса. И вот, допустим я хочу посмотреть план выполнения EXPLAIN SELECT * FROM some_table.
На что получаю:
Seq Scan on some_table (cost=0.00..2.86 rows=86 width=75)
Выходит, что было переборов всего 86 штук, в то время как строк в таблице 105 штук. Или в этом случае происходит INDEX SCAN, а не TABLE SCAN? Т.е перебор идет не по всей таблице, а по бакетам b-дерева?
rows тянется из статистики, которая может быть несколько устаревшей
> Имею базу на постгрессе. И почему бы не спрашивать в чате по нему? https://t.me/pgsql > Выходит, что было переборов всего 86 штук, в то время как строк в таблице 105 штук Нет, "rows=86" — это не количество "переборов", это оценочное количество возвращаемых этим узлом плана записей. > Или в этом случае происходит INDEX SCAN, а не TABLE SCAN? Т.е перебор идет не по всей таблице, а по бакетам b-дерева? Нет и нет. Что написано (seq.scan), то и будет выполнено.
Если в таблице 100 строку, никакие индексы не нужны и на будут использоваться
Обсуждают сегодня