| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
| Cc: | Douglas J Hunley <doug(at)hunley(dot)homeip(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: 7 hrs for a pg_restore? |
| Date: | 2008-02-19 19:51:19 |
| Message-ID: | 1203450679.3846.107.camel@dogma.ljc.laika.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, 2008-02-19 at 14:28 -0500, Dave Cramer wrote:
> shared buffers is *way* too small as is effective cache
> set them to 2G/6G respectively.
They are way too small, but I don't think that explains the index
creation time.
Effective_cache_size is only used by the planner, and this problem is
not caused by a poorly chosen plan.
It's important to set shared_buffers higher as well, but he has so much
RAM compared with his dataset that he's certainly not going to disk. I
don't think this explains it either.
I think it's just the result of building a lot of indexes on localized
text using only one core at a time.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff | 2008-02-19 20:07:30 | Re: 7 hrs for a pg_restore? |
| Previous Message | Jeff Davis | 2008-02-19 19:46:07 | Re: 7 hrs for a pg_restore? |