Индек для NULL значений

Добрый день.

Есть таблица в которой 86 млн записей. Из них по одному из полей (назовем это поле - highway) 77 млн записей имеют не NULL значения, а 9 млн записей соответственно NULL.
Запрос на выборку данных содержит выражение highway is not null, это естественно приводит к полному сканированию таблицы.
Вопрос. Есть ли возможность создать индекс, который позволит повысить скорость выполнения запроса?
Или есть еще какие-нибудь рекомендации по этой проблеме

Сам запрос

select way from planet_osm_line where highway is not null

План его выполнения

Seq Scan on planet_osm_line  (cost=0.00..4180162.44 rows=76922688 width=258)

Забыл сказать, что тип поля - TEXT

big-trot,

но куда ты потом засовываешь эти 77 млн, полученные запросом?!!

big-trot

Добрый день. Есть таблица в которой 86 млн записей. Из них по одному из полей (назовем это поле - highway) 77 млн записей имеют не NULL значения, а 9 млн записей соответственно NULL. Запрос на выборку данных содержит выражение highway is not null, это естественно приводит к полному сканированию таблицы. Вопрос. Есть ли возможность создать индекс, который позволит повысить скорость выполнения запроса? Или есть еще какие-нибудь рекомендации по этой проблеме Сам запрос select way from planet_osm_line where highway is not null План его выполнения Seq Scan on planet_osm_line (cost=0.00..4180162.44 rows=76922688 width=258)

Любой запрос выбирающий больше 10% таблицы всегда быстрее сделать seq scan ном.

--Maxim Boguk
www.postgresql-consulting.ru

Maxim Boguk
<> Любой запрос выбирающий больше 10% таблицы всегда быстрее сделать seq scan ном. --Maxim Boguk

таблица может быть очень широкой, выборка очень узкой, индекс очень актуальным, и покрывающим.

т.е если под 10% загонять и ширину -- то скорее да (даже и 5%, скорее всего), а если только процент от числа записей -- то it depends.

эээээ
Maxim Boguk <> Любой запрос выбирающий больше 10% таблицы всегда быстрее сделать seq scan ном. --Maxim Boguk таблица может быть очень широкой, выборка очень узкой, индекс очень актуальным, и покрывающим. т.е если под 10% загонять и ширину -- то скорее да (даже и 5%, скорее всего), а если только процент от числа записей -- то it depends.

это так вы правы конечно. Но для уровня автора вопроса это будет слишком сложный ответ, тем более что в данном случае тут выбирается больше 90% строк.

Проблема c IOS в том что он читает страницы в порядке индекса и дает random read а не seq scan... и чтобы выборка большей части строк таблицы через IOS была эффективной индекс должен очень узкий и компактный (и хорошо закешированный) по сравнению с таблицей.

--Maxim Boguk
www.postgresql-consulting.ru

b-tree уже давно индексирует нулы в pg. (с 8.2 чтоли) но тут конечно это бессмыслено. А особенно пихать в индекс TEXT.
Ну и воообще - выбрать быстро 77 млн текстов - это что-то из разряда noSQL

Ivan Durak
Ну и воообще - выбрать быстро 77 млн текстов - это что-то из разряда noSQL

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

Ivan Durak
<> Ну и воообще - выбрать быстро 77 млн текстов - это что-то из разряда noSQL

гм, сделайте шардирование пж через plproxy нод эдак на 128 -- будете в параллель сексканить по полляма записей с ноды (без педантичных излишеств в виде координатора распред.-- транзакций).

"быстро" проистекает не из NoSql, а из NoACID, но маркетинг помогает путаться в словах, в нужную ему сторону

big-trot,

Ну можете создать условный индекс типа

CREATE INDEX scheta_neuplocheno ON s cheta ( id ) WHERE uplocheno not null
;

. Пустые просто не попадут в индекс. Хотя как уже сказали, при выборке 77 млн из 90 это не сильно поможет, нужно анализировать запрос в целом. Если клиент получает все 77 млн, то нужно менять архитектуру приложения.