To: Greg Smith <greg@2ndquadrant.com>
cc: jd@commandprompt.com, Ogden <lists@darkstatic.com>,
	Jesper Krogh <jesper@krogh.cc>, Kenneth Marshall <ktm@rice.edu>,
	pgsql-performance@postgresql.org
Subject: Re: Query much faster with enable_seqscan=0 
In-reply-to: <4C9904A9.5080301@2ndquadrant.com> 
References: <0D5B9ED0-00C3-4EEB-8336-0B2F8A884620@darkstatic.com>
	<20100921180618.GI17152@aart.is.rice.edu>
	<D707045F-C689-403A-9729-8DBCC39F53A1@darkstatic.com>
	<4C98FEA2.8030607@krogh.cc>
	<3062DF4E-7460-4487-818A-BF77F176E501@darkstatic.com>
	<1285096031.15919.68.camel@jd-desktop.unknown.charter.com>
	<4C9904A9.5080301@2ndquadrant.com>
Comments: In-reply-to Greg Smith <greg@2ndquadrant.com>
	message dated "Tue, 21 Sep 2010 15:16:57 -0400"
Date: Tue, 21 Sep 2010 19:24:47 -0400
Message-ID: <11632.1285111487@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Greg Smith <greg@2ndquadrant.com> writes:
> and the query optimizer needs to be careful about what it does and 
> doesn't pull from disk.  If that's not the case, like here where there's 
> 8GB of RAM and a 7GB database, dramatic reductions to both seq_page_cost 
> and random_page_cost can make sense.  Don't be afraid to think lowering 
> below 1.0 is going too far--something more like 0.01 for sequential and 
> 0.02 for random may actually reflect reality here.

If you are tuning for an all-in-RAM situation, you should set
random_page_cost equal to seq_page_cost (and usually set both smaller
than 1).  By definition, those costs are equal if you're fetching from
RAM.  If it's only mostly-in-RAM then keeping random_page_cost a bit
higher makes sense.

			regards, tom lane