| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Joshua Marsh <icub3d(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org, jim(at)nasby(dot)net |
| Subject: | Re: Performance With Joins on Large Tables |
| Date: | 2006-09-13 16:07:34 |
| Message-ID: | 1158163655.29889.57.camel@dogma.v10.wvs |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, 2006-09-13 at 08:49 -0600, Joshua Marsh wrote:
> That seems to have done it. Are there any side effects to this
> change? I read about random_page_cost in the documentation and it
> seems like this is strictly for planning. All the tables on this
> database will be indexed and of a size similar to these two, so I
> don't see it causing any other problems. Though I would check though
> :)
>
Right, it's just used for planning. Avoid setting it too low, if it's
below about 2.0 you would most likely see some very strange plans.
Certainly it doesn't make sense at all to set it below 1.0, since that
is saying it's cheaper to get a random page than a sequential one.
What was your original random_page_cost, and what is the new value you
set it to?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Marsh | 2006-09-13 16:19:04 | Re: Performance With Joins on Large Tables |
| Previous Message | Tom Lane | 2006-09-13 15:32:48 | Re: sql-bench |