To: David Jarvis <thangalin@gmail.com>
cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
Subject: Re: Random Page Cost and Planner 
In-reply-to: <AANLkTin-j4SACaMeJCH4r5ekEWrtuiFqU56gVM1_lIyV@mail.gmail.com> 
References: <AANLkTikS_QvlkYfv5_hbsXFH4SsTh1nP_WoTwRqpUUcz@mail.gmail.com>
	<4BFBD0890200002500031A6E@gw.wicourts.gov>
	<AANLkTin-j4SACaMeJCH4r5ekEWrtuiFqU56gVM1_lIyV@mail.gmail.com>
Comments: In-reply-to David Jarvis <thangalin@gmail.com>
	message dated "Tue, 25 May 2010 16:26:52 -0700"
Date: Tue, 25 May 2010 20:24:23 -0400
Message-ID: <2008.1274833463@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

David Jarvis <thangalin@gmail.com> writes:
>> It sounds as though the active portion of your database is pretty
>> much cached in RAM.  True?

> I would not have thought so; there are seven tables, each with 39 to 43
> million rows as: [ perhaps 64 bytes per row ]
> The machine has 4GB of RAM, donated to PG as follows:

Well, the thing you need to be *really* wary of is setting the cost
parameters to make isolated tests look good.  When you repeat a
particular test case multiple times, all times after the first probably
are fully cached ... but if your DB doesn't actually fit in RAM, that
might not be too representative of what will happen under load.
So if you want to cut the xxx_page_cost settings some more, pay close
attention to what happens to average response time.

			regards, tom lane