Re: FTS performance issue - planner problem identified (but only partially resolved)

Поиск
Список
Период
Сортировка
От Stefan Keller
Тема Re: FTS performance issue - planner problem identified (but only partially resolved)
Дата
Msg-id CAFcOn29m3Mgvn+PZetDsb0_s7OjgGKU3iML5budw9V9eLo21zQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FTS performance issue - planner problem identified (but only partially resolved)  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-performance
Hi Kevin

Well, you're right :-) But my use cases are un-specific "by design"
since I'm using FTS as a general purpose function.

So I still propose to enhance the planner too as Tom Lane and your
colleague suggest based on repeated similar complaints [1].

Yours, Stefan

[1] http://www.postgresql.org/message-id/CA+TgmoZgQBeu2KN305hwDS+aXW7YP0YN9vZwBsbWA8Unst+cew@mail.gmail.com


2013/7/29 Kevin Grittner <kgrittn@ymail.com>:
> Stefan Keller <sfkeller@gmail.com> wrote:
>
>> Finally, setting random_page_cost to 1 helps also - but I don't
>> like this setting neither.
>
> Well, you should learn to like whichever settings best model your
> actual costs given your level of caching and your workload.  ;-)
> FWIW, I have found page costs less volatile and easier to tune
> with cpu_tuple_cost increased.  I just always start by bumping
> that to 0.03.
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company


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

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: FTS performance issue - planner problem identified (but only partially resolved)
Следующее
От: Jeison Bedoya
Дата:
Сообщение: to many locks held