Re: [PERFORM] Performance suggestions for an update-mostly database?
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 [EMAIL PROTECTED]) > -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] 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?" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Performance suggestions for an update-mostly database?
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] Performance suggestions for an update-mostly database?
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] Performance suggestions for an update-mostly database?
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 [EMAIL PROTECTED])
[PERFORM] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
