From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Joseph S <jks(at)selectacast(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: What exactly is postgres doing during INSERT/UPDATE ? |
Date: | 2009-08-31 19:15:56 |
Message-ID: | dcc563d10908311215hd089c93w471ca3590cc33df2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 31, 2009 at 10:31 AM, Kevin
Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> Joseph S <jks(at)selectacast(dot)net> wrote:
>
>>> The question is what I do with my 14 drives. Should I use only 1
>>> pair for indexes or should I use 4 drives? The wal logs are
>>> already slated for an SSD.
>
>> Why not just spread all your index data over 14 spindles, and do the
>> same with your table data?
>
> If you have the luxury of being able to test more than one
> configuration with something resembling your actual workload, I would
> strongly recommend including this as one of your configurations.
> Spreading everything over the larger number of spindles might well
> out-perform your most carefully hand-crafted tuning of object
> placement on smaller spindle sets.
The first thing I'd test would be if having a separate mirror set for
pg_xlog helps. If you have a high write environment moving pg_xlog
off of the main data set can help a lot.
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Ivanov | 2009-09-01 00:19:01 | Re: Number of tables |
Previous Message | Kevin Grittner | 2009-08-31 16:31:13 | Re: What exactly is postgres doing during INSERT/UPDATE ? |