[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 sh

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 d

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 th

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 docu

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 kin