Re: [PERFORM] Performance considerations for very heavy INSERT traffic

2005-09-13 Thread Brandon Black
On 9/12/05, Christopher Petrilli [EMAIL PROTECTED] wrote: 3) Use 8.1 and strongly look at Bizgres. The data partitioning is critical. I started looking closer at my options for partitioning (inheritance, union all), and at Bizgres today. Bizgres partitioning appears to be basically the same kind

[PERFORM] Performance considerations for very heavy INSERT traffic

2005-09-12 Thread Brandon Black
I'm in the process of developing an application which uses PostgreSQL for data storage. Our database traffic is very atypical, and as a result it has been rather challenging to figure out how to best tune PostgreSQL on what development hardware we have, as well as to figure out exactly what we

Re: [PERFORM] Performance considerations for very heavy INSERT traffic

2005-09-12 Thread Brandon Black
On 9/12/05, PFC [EMAIL PROTECTED] wrote: I know I haven't provided a whole lot of application-level detail here,You did !What about :- using COPY instead of INSERT ?(should be easy to do from the aggregators) Possibly, although it would kill the current design of returning the database

Re: [PERFORM] Performance considerations for very heavy INSERT traffic

2005-09-12 Thread Brandon Black
On 12 Sep 2005 23:07:49 -0400, Greg Stark [EMAIL PROTECTED] wrote: The WAL parameters like commit_delay and commit_siblings are a bit of amystery. Nobody has done any extensive testing of them. It would be quite helpful if you find anything conclusive and post it. It would also besurprising if

Re: [PERFORM] Performance considerations for very heavy INSERT traffic

2005-09-12 Thread Brandon Black
On 9/12/05, Christopher Petrilli [EMAIL PROTECTED] wrote: 2) Tune ext3.The default configuration wrecks high-write situations. Look into data="" for mounting, turning off atime (I hopeyou've done this already) updates, and also modifying the scheduler to the elevator model.This is poorly