Re: FTS performance issue probably due to wrong planner estimate of detoasting

Поиск
Список
Период
Сортировка
От Jesper Krogh
Тема Re: FTS performance issue probably due to wrong planner estimate of detoasting
Дата
Msg-id 5114A183.3090502@krogh.cc
обсуждение исходный текст
Ответ на FTS performance issue probably due to wrong planner estimate of detoasting  (Stefan Keller <sfkeller@gmail.com>)
Ответы Re: FTS performance issue probably due to wrong planner estimate of detoasting  (Stefan Keller <sfkeller@gmail.com>)
Список pgsql-performance
On 08/02/13 01:52, Stefan Keller wrote:
> Hi,
>
> I have problems with the performance of FTS in a query like this:
>
>    SELECT * FROM FullTextSearch WHERE content_tsv_gin @@
> plainto_tsquery('english', 'good');
>
> It's slow (> 30 sec.) for some GB (27886 html files, originally 73 MB zipped).
> The planner obviously always chooses table scan: http://explain.depesz.com/s/EEE
> I have to check again, if I'm doing something wrong but I'm pretty
> sure it has to do with de-toasting and (wrong?) cost estimations.
If you havent done it .. bump up statistics target on the column and
re-analyze, see what that gives.

I have also been playing with the cost-numbers in order to get it to favour
an index-scan more often. That is lowering random_page_cost to be close to
seq_page_cost, dependent on your system, the amount of memory, etc, then
this can have negative side-effects on non-gin-queries.

--
Jesper


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: FTS performance issue probably due to wrong planner estimate of detoasting
Следующее
От: Karolis Pocius
Дата:
Сообщение: Slow query even with aggressive auto analyze