From: | Stefan Keller <sfkeller(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: FTS performance issue - planner problem identified (but only partially resolved) |
Date: | 2013-07-29 23:29:46 |
Message-ID: | CAFcOn29m3Mgvn+PZetDsb0_s7OjgGKU3iML5budw9V9eLo21zQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
2013/7/29 Kevin Grittner <kgrittn(at)ymail(dot)com>:
> Stefan Keller <sfkeller(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeison Bedoya | 2013-07-30 10:52:28 | to many locks held |
Previous Message | Kevin Grittner | 2013-07-29 20:28:56 | Re: FTS performance issue - planner problem identified (but only partially resolved) |