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@xxxxxxxxxxxxxx 2013/7/29 Kevin Grittner <kgrittn@xxxxxxxxx>: > Stefan Keller <sfkeller@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
