Re: Performance suggestions for an update-mostly database?

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Steve Atkins <steve(at)blighty(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance suggestions for an update-mostly database?
Date: 2004-10-04 19:22:54
Message-ID: 20041004192254.GT1297@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

And obviously make sure you're vacuuming frequently.

On Mon, Oct 04, 2004 at 10:38:14AM -0700, Josh Berkus wrote:
> Steve,
>
> > I'm used to performance tuning on a select-heavy database, but this
> > will have a very different impact on the system. Does anyone have any
> > experience with an update heavy system, and have any performance hints
> > or hardware suggestions?
>
> Minimal/no indexes on the table(s). Raise checkpoint_segments and consider
> using commit_siblings/commit_delay if it's a multi-stream application.
> Figure out ways to do inserts instead of updates where possible, and COPY
> instead of insert, where possible. Put your WAL on its own disk resource.
>
> I'm a little curious as to what kind of app would be 95% writes. A log?
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Miles Keaton 2004-10-04 23:27:51 would number of fields in a table affect search-query time?
Previous Message Jim C. Nasby 2004-10-04 19:18:50 Re: Caching of Queries