| From: | Francisco Reyes <lists(at)stringsutils(dot)com> |
|---|---|
| To: | Jim C(dot) Nasby <jnasby(at)pervasive(dot)com> |
| Cc: | Chris <dmagick(at)gmail(dot)com>, Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Inserts optimization? |
| Date: | 2006-04-14 11:30:25 |
| Message-ID: | cone.1145014225.784898.23930.1000@zoraida.natserv.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jim C. Nasby writes:
> On Thu, Apr 13, 2006 at 02:59:23PM -0400, Francisco Reyes wrote:
>> In RAID 10 would it matter that WALL is in the same RAID set?
>> Would it be better:
>> 4 disks in RAID10 Data
>> 2 disks RAID 1 WALL
>> 2 hot spares
>
> Well, benchmark it with your app and find out, but generally speaking
> unless your database is mostly read you'll see a pretty big benefit to
> seperating WAL from table/index data.
That will not be easy to compare.. it would mean setting up the machine..
trashing it.. then redoing the whole setup..
I am leaning towards using pgbench against the current machine to see what
parameters affect inserts.. perhaps also doing dome tests with just inserts
from a file. Then using the same setups on the next machine and just go with
RAID10 on the 6 disks. Split the raid into 10 may give me space issues to
deal with.
Will also find out if the app, Bacula, batches transactions or not.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Stone | 2006-04-14 11:49:14 | Re: Inserts optimization? |
| Previous Message | patrick keshishian | 2006-04-14 07:10:57 | Re: pg 7.4.x - pg_restore impossibly slow |