Чи може PostgreSQL використовувати нулі у своїх індексах?

Я читав цю книгу, яка говорить про це

База даних передбачає, що Indexed_Col НЕ NULL охоплює занадто великий діапазон, щоб бути корисним, тому база даних не буде запускати до індексу з цієї умови.

Я усвідомлюю, що книзі вже більше 10 років, але вона вже виявилася досить корисною - використовуючи інструкції, зібрані зі своїх сторінок, я заробив запит у десять разів.

Далі, працюючи EXPLAIN ANALYZEнад SELECTзапитом, я виявив, що жоден з моїх індексів не використовується, навіть коли за всіма правами вони повинні бути.

Таким чином, моє питання:

Припустимо, що існує таблиця з стовпцем, визначення якої стовпця містить "NOT NULL", і що існує індекс, який охоплює цей стовпець, чи буде цей індекс використаний у запиті тієї таблиці, де стовпці є частиною запиту?

Подібно до:

CREATE TABLE my_table(
a varchar NOT NULL
);

CREATE INDEX ix_my_table ON my_table(a);

SELECT a from my_table;

PostgreSQL, безумовно, може використовувати індекс для IS NOT NULL. Я не бачу припущень планувальника запитів щодо цієї умови.

Якщо нульова частка для стовпця ( pg_statistic.stanullfrac) є достатньо низькою, щоб припустити, що індекс корисно вибірковий для запиту, PostgreSQL використовуватиме індекс.

Я не можу зрозуміти, що ти намагаєшся сказати:

Якщо це правильно, чи я розумію, що індекс у стовпці, визначеному як "NOT NULL", не використовується у запиті, який використовує цей стовпець?

Звичайно, індекс не звикне до IS NOT NULLумови в NOT NULLстовпці. Він завжди збігався б на 100% рядків, тому послідовно майже завжди буде набагато швидше.

PostgreSQL не використовуватиме індекс, якщо індекс не відфільтрує велику частку рядків для запиту. Єдине ймовірне виняток - коли ви запитуєте набір стовпців, охоплених одним індексом, у порядку, що відповідає рівню індексу. Потім PostgreSQL може виконати сканування лише з індексом. Наприклад, якщо на вас є індекс t(a, b, c):

select a, b FROM t ORDER BY a, b, c;

PostgreSQL може використовувати ваш індекс, навіть якщо жодні рядки не відфільтровані, тому що він повинен лише зчитувати індекс і може пропустити читання купи, уникаючи сортування тощо.

На додаток до ґрунтовної відповіді Крейга, я хотів додати, що обкладинка книги, на яку ви посилаєтесь, говорить:

Охоплює Oracle, DB2 та SQL Server

Тому я б не вірив, що це є чудовим джерелом порад щодо PostgreSQL, зокрема. Кожен RDBMS може бути напрочуд різним!

Я трохи розгублений у вашому первісному запитанні, але ось приклад, який показує, що розділ книги не на 100% правильний. Щоб уникнути подальшої плутанини, ось весь відповідний параграф, ви можете побачити його в пошуку книг Google .

База даних передбачає, що Indexed_Col НЕ NULL охоплює занадто великий діапазон, щоб бути корисним, тому база даних не буде запускати до індексу з цієї умови. У рідкісних випадках наявність ненульового значення настільки рідко, що сканування діапазону індексу над усіма можливими ненульовими значеннями є вигідним. У таких випадках, якщо ви можете встановити безпечну нижню або верхню межу діапазону всіх можливих значень, ви можете ввімкнути сканування діапазону з умовою, такою як Positive_ID_Column> -1 або Date_Column> TO_DATE ('0001/01/01' , "РРРР / ММ / ДД").

Postgres може фактично (у наступному надуманому випадку) використовувати індекс для задоволення IS NOT NULLзапитів без додавання діапазонів сканування діапазону, як запропоновано Positive_ID_Column > -1. Дивіться коментарі до питань Крейга, чому Postgres вибирає саме цей індекс у даному конкретному випадку, та примітку про використання часткових індексів.

CREATE TABLE bar (a int);
INSERT INTO bar (a) SELECT NULL FROM generate_series(1,1000000);
INSERT INTO bar (a) VALUES (1);
CREATE INDEX bar_idx ON bar (a);

EXPLAIN ANALYZE SELECT * FROM bar WHERE a IS NOT NULL;
                                                QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Index Only Scan using bar_idx on bar  (cost=0.42..8.44 rows=1 width=4) (actual time=0.094..0.095 rows=1 loops=1)
   Index Cond: (a IS NOT NULL)
   Heap Fetches: 1
 Total runtime: 0.126 ms
(4 rows)

Це, до речі, Postgres 9.3, але я вважаю, що результати були б приблизно подібними на 9.1, хоча він не використовував би "Сканувати тільки з індексом".

Редагувати: Я бачу, що ви уточнили своє початкове запитання, і вам, мабуть, цікаво, чому Postgres не використовує індекс у простому прикладі, як-от:

CREATE TABLE my_table(
a varchar NOT NULL
);

CREATE INDEX ix_my_table ON my_table(a);

SELECT a from my_table;

Можливо, тому, що у вас немає рядків у таблиці. Тому додайте деякі тестові дані та ANALYZE my_table;.

Ви не опублікували дані запиту чи прикладу. Але найпоширеніші причини, за якими не використовуються індекси, пов'язані з обсягом.

Покажчики схожі на телефонну книгу, яка переводить стовпець у місцеположення рядків. Якщо ви шукаєте лише кілька рядків, є сенс шукати кожен рядок у телефонній книзі, а потім шукати рядок у головній таблиці.

Але для кількох рядків дешевше пропустити телефонну книгу та повторити всі рядки в головній таблиці. На мій досвід, точка відбиття становить близько 100 рядів.