Thread: Performance suggestions for an update-mostly database?
I'm putting together a system where the operation mix is likely to be >95% update, <5% select on primary key. 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? Cheers, Steve
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
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. Thanks. > I'm a little curious as to what kind of app would be 95% writes. A log? It's the backend to a web application. The applications mix of queries is pretty normal, but it uses a large, in-core, write-through cache between the business logic and the database. It has more than usual locality on queries over short time periods, so the vast majority of reads should be answered out of the cache and not touch the database. In some ways something like Berkeley DB might be a better match to the frontend, but I'm comfortable with PostgreSQL and prefer to have the power of SQL commandline for when I need it. Cheers, Steve
Steve, > In some ways something like Berkeley DB might be a better match to the > frontend, but I'm comfortable with PostgreSQL and prefer to have the > power of SQL commandline for when I need it. Well, if data corruption is not a concern, you can always turn off checkpointing. This will save you a fair amount of overhead. You could also look at telegraphCQ. It's not prodcucton yet, but their idea of "streams" as data sources really seems to fit with what you're talking about. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
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@postgresql.org) > -- Jim C. Nasby, Database Consultant decibel@decibel.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?"