| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Jarvis <thangalin(at)gmail(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Random Page Cost and Planner |
| Date: | 2010-05-26 00:24:23 |
| Message-ID: | 2008.1274833463@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
David Jarvis <thangalin(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rob Wultsch | 2010-05-26 00:56:58 | Re: Random Page Cost and Planner |
| Previous Message | David Jarvis | 2010-05-25 23:26:52 | Re: Random Page Cost and Planner |