DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=bkkhzTMxjzTCuvg1gQXtSJND7fgXSAQpTx5pJo6rr7H4airoLmojJCRqUdQFO0LlxSImCNKGg/2Tz1+Ql1PV68bIB7zSPN3k2zEC6PkUcnSWNLDnDSrphkCffkVoLEaiUmhe1lVC2qalyVrW0jelwefloMBRwrGNA+suvzvsK3I=;
References: <5224ED90.7030808@gmx.net>
Message-ID: <1378234920.66126.YahooMailNeo@web162906.mail.bf1.yahoo.com>
Date: Tue, 3 Sep 2013 12:02:00 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: planner parameters
To: =?iso-8859-1?Q?Torsten_F=F6rtsch?= <torsten.foertsch@gmx.net>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <5224ED90.7030808@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Torsten F=F6rtsch <torsten.foertsch@gmx.net> wrote:

> Is there an other way to make the planner use generate the 1st
> plan?

The planner cost factors are based on the assumption that a
moderate percentage of random page reads will need to actually go
out to disk.=A0 If a high percentage of pages are in cache, you may
want to reduce random_page_cost to something closer to (or even
equal to) seq_page_cost.=A0 I generally find I get better plans if I
raise cpu_tuple_cost to 0.03.=A0 effective_cache_size should
generally be between 50% and 75% of machine RAM.=A0 If these changes
(or others of their ilk) cause costs to be estimated in a way which
more nearly matches reality, better plans will be chosen.

> Why does it generate the 2nd plan at all?

It has the lowest estimated cost, based on your memory
configuration and cost factors.

> Does the planner take into account what is currently present in
> shared memory?

No.=A0 If you search the archives you can probably find previous
discussions of whether it would be a good idea to do so; the
consensus has been that it would not be.

If you have further performance-related questions, please review
this page so that you can provide enough information to allow
people to give the most helpful advice:

http://wiki.postgresql.org/wiki/SlowQueryQuestions

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


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance