Низкая производительность индекса varchar в Postgres - PullRequest
0 голосов
/ 13 января 2019

У меня есть таблица с ~ 500 000 строк со столбцом со значениями вроде Brutus, Dreamer of the Wanton Wasteland. Мне нужно выполнить нечувствительный к регистру запрос LIKE по ним, но, похоже, он выполняется очень медленно. Я попытался сделать индекс с:

create index name_idx on deck (name);

и

create index deck_name_idx on deck (lower(name));

Но запрос одинаково медленный в любом случае. Вот мой запрос:

select * 
    from deck 
    where lower(deck.name) like '%brutus, dreamer of the%' 
    order by deck.id desc 
    limit 20

Вот результаты моего анализа объяснения (это со вторым индексом, но оба одинаково медленны.)

Limit  (cost=152534.89..152537.23 rows=20 width=1496) (actual time=627.480..627.490 rows=1 loops=1)
  ->  Gather Merge  (cost=152534.89..152539.56 rows=40 width=1496) (actual time=627.479..627.488 rows=1 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        ->  Sort  (cost=151534.87..151534.92 rows=20 width=1496) (actual time=611.447..611.447 rows=0 loops=3)
              Sort Key: id DESC
              Sort Method: quicksort  Memory: 25kB
              ->  Parallel Seq Scan on deck  (cost=0.00..151534.44 rows=20 width=1496) (actual time=609.818..611.304 rows=0 loops=3)
                    Filter: (lower((name)::text) ~~ '%brutus, dreamer of the%'::text)
                    Rows Removed by Filter: 162210
Planning time: 0.786 ms
Execution time: 656.510 ms

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

1 Ответ

0 голосов
/ 14 января 2019

Для поддержки LIKE запросов без подстановочных знаков в начале используйте

CREATE INDEX ON deck (lower(name) varchar_pattern_ops);

Для поддержки LIKE поисков, которые могут иметь подстановочный знак в начале, вы можете

CREATE EXTENSION pg_trgm;
CREATE INDEX ON deck USING gin (lower(name) gin_trgm_ops);
...