pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Thomas Finneid <tfinneid@student.matnat.uio.no>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: pgsql-performance@postgresql.org
Subject: Re: slow update of index during insert/copy
Date: Mon, 1 Sep 2008 14:42:07 -0600
Message-ID: <dcc563d10809011342i55d32d23la4604e71d19dfdb0@mail.gmail.com> (raw)
In-Reply-To: <48BC5178.60906@ifi.uio.no>
References: <48BA9D65.2020001@ifi.uio.no>
	<48BB4A2D.9080404@postnewspapers.com.au>
	<48BBD22E.4090308@ifi.uio.no>
	<dcc563d10809011051s558f8a7bp5beb0dbe181721e4@mail.gmail.com>
	<a1ec7d000809011146x456b942eof33627c63f8a021a@mail.gmail.com>
	<48BC5178.60906@ifi.uio.no>

On Mon, Sep 1, 2008 at 2:32 PM, Thomas Finneid
<tfinneid@student.matnat.uio.no> wrote:
>
> Scott Carey wrote:
>>
>> For a development box, just enable write-back caching regardless of the
>> battery back up situation.  As long as its not your only copy of
>
> Will have a look at it, the data is not important and can be reproduced any
> time on any machine. The controller I have is a Areca ARC-1220 Serial ATA 8
> port RAID Controller - PCI-E, SATA II, so I dont know exactly what it
> supports of caching.

It's a pretty good card.  It should support 1G of cache at least, and
definitely supports battery backup.  Have had a pair of 1680 Arecas in
production for a month now and so far I'm very happy with the
reliability and performance.

The other Scott is technically right about the lack of need for
battery back on a dev machine as long as you go in and change the
chaching to write back, and I'm sure the card will give you a red
dialog box saying this is a bad idea. Now, if it would take you a day
of downtime to get a dev database back in place and running after a
power loss, then the bbu may be worth the $200 or so.

While I like to have a machine kitted out just like prod for testing,
for development I do tend to prefer slower machines, so that
developers might notice if they've just laid a big fat bloaty code
egg that's slower than it should be.  Try to optimize for acceptable
performance on such server and you're far more likely to get good
performance behaviour in production.



view thread (22+ messages)  latest in thread

Message-ID: <dcc563d10809011342i55d32d23la4604e71d19dfdb0@mail.gmail.com>
Permalink:  ../dcc563d10809011342i55d32d23la4604e71d19dfdb0@mail.gmail.com/
Also on:    postgresql.org/message-id/dcc563d10809011342i55d32d23la4604e71d19dfdb0@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: scott.marlowe@gmail.com, tfinneid@student.matnat.uio.no, scott@richrelevance.com, craig@postnewspapers.com.au
  Subject: Re: slow update of index during insert/copy
  In-Reply-To: <dcc563d10809011342i55d32d23la4604e71d19dfdb0@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox