Re: Weirdly pesimistic estimates in optimizer

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: David Kubečka <kubecka(dot)dav(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Weirdly pesimistic estimates in optimizer
Date: 2015-03-03 13:56:19
Message-ID: 1172896564.922252.1425390979021.JavaMail.yahoo@mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Kubečka <kubecka(dot)dav(at)gmail(dot)com> wrote:

> I have read the optimizer README file and also looked briefly at
> the code, but this seems to be something not related to
> particular implementation of algorithm (e.g. nested loop).
> Perhaps it's the way how cost estimates are propagated down

It could be as simple as not having tuned your cost factors to
accurately reflect the relative costs of different actions in your
environment. If you are using the default configuration, you might
want to try a few of the adjustments that are most often needed (at
least in my experience):

cpu_tuple_cost = 0.03
random_page_cost = 2
effective_cache_size = <50% to 75% of machine RAM>
work_mem = <machine RAM * 0.25 / max_connections>

You can SET these on an individual connection, one at a time or in
combination, and EXPLAIN the query to see the effects on plan
choice.

Other advice, not all of which matches my personal experience, can
be found here:

https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

The best thing to do is experiment with different values with your
own queries and workloads to see what most accurately models your
costs (and thus produces the fastest plans).

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan de Visser 2015-03-03 14:19:34 Re: Idea: closing the loop for "pg_ctl reload"
Previous Message Vladimir Borodin 2015-03-03 13:55:56 Re: pg_upgrade and rsync