Re: Why is this query not using GIN index?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why is this query not using GIN index?
Дата
Msg-id 1273.1479063104@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why is this query not using GIN index?  (Oleg Bartunov <obartunov@gmail.com>)
Ответы Re: Why is this query not using GIN index?  (Aaron Lewis <the.warl0ck.1989@gmail.com>)
Список pgsql-general
Oleg Bartunov <obartunov@gmail.com> writes:
> On Sun, Nov 13, 2016 at 6:05 PM, Aaron Lewis <the.warl0ck.1989@gmail.com>
>> It takes 500ms with 10m rows, could it be faster?

> sure.  Recheck with function call is pretty expensive, so I'd not recommend
> to create functional index, just create separate column of type tsvector
> (materialize to_tsvector) and create gin index on it.  You should surprise.

I doubt it'll help that much --- more than half the time is going into the
bitmap indexscan, and with over 1m candidate matches, there's no way
that's going to be super cheap.

I wonder whether a gist index would be better here, since it would support
a plain indexscan which should require scanning much less of the index
given the small LIMIT.

(Materializing the tsvector would probably help for gist, too, by reducing
the cost of lossy-index rechecks.)

BTW, it still looks like the performance is being significantly hurt by
inadequate work_mem.

            regards, tom lane


В списке pgsql-general по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: Why is this query not using GIN index?
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: Trigram is slow when 10m rows