DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=li4qBUfsU+z2Aq/Or4lBNLN1A66MQxXfDxyh08Wp+8DdjpiSF6wM6YEpHGK0emksOx
	DDRjv+egplYIzqX8bkyn62etrjCbiTPGljOz8RlO9e0SRmgrjEQwLk80RCiOFqIesOJq
	JYR3Fk7Ln3tvREgB1amzMSBl+O0/cMJAM0bOQ=
MIME-Version: 1.0
In-Reply-To: <49A295F0.5010405@saparev.com>
References: <49A295F0.5010405@saparev.com>
Date: Mon, 23 Feb 2009 09:53:41 -0500
Message-ID: <603c8f070902230653v346f5b5cm6aeceedce7903f5@mail.gmail.com>
Subject: Re: LIMIT confuses the planner
From: Robert Haas <robertmhaas@gmail.com>
To: kouber@saparev.com
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Feb 23, 2009 at 7:26 AM, Kouber Saparev <kouber@saparev.com> wrote:
> Now, recently I have altered some of the default parameters in order to get
> as much as possible out of the hardware - 12 GB of RAM, 8 processors. So, I
> guess I have done something wrong, thus the planner is taking that wrong
> decision. Here's what I have changed in postgresql.conf (from the default
> one):
>
> max_connections = 200
> shared_buffers = 256MB
> work_mem = 64MB
> maintenance_work_mem = 128MB
> max_stack_depth = 6MB
> max_fsm_pages = 100000
> synchronous_commit = off
> wal_buffers = 1MB
> commit_delay = 100
> commit_siblings = 5
> checkpoint_segments = 10
> checkpoint_timeout = 10min
> random_page_cost = 0.1
> effective_cache_size = 2048MB
>
> Any idea what's wrong here?

If you left seq_page_cost (which isn't mentioned here) at the default
value but reduced random_page_cost to 0.1, then you have
random_page_cost < seq_page_cost.  That's probably Bad.

...Robert