Re: [PERFORM] [HACKERS] fsync method checking

On 25 Mar, Manfred Spraul wrote: > Tom Lane wrote: > >>[EMAIL PROTECTED] writes: >> >> >>>I could certainly do some testing if you want to see how DBT-2 does. >>>Just tell me what to do. ;) >>> >>> >> >>Just do some runs that are identical except for the wal_sync_method >>setting. Note that

Re: [PERFORM] [HACKERS] fsync method checking

ave any impact on SELECT > performance, only insert/update/delete performance. Ok, here are the results I have from my 4-way xeon system, a 14 disk volume for the log and a 52 disk volume for everything else: http://developer.osdl.org/markw/pgsql/wal_sync_method.html 7.5devel-2

Re: [PERFORM] [HACKERS] fsync method checking

On 26 Mar, Bruce Momjian wrote: > [EMAIL PROTECTED] wrote: >> On 26 Mar, Manfred Spraul wrote: >> > [EMAIL PROTECTED] wrote: >> > >> >>Compare file sync methods with one 8k write: >> >>(o_dsync unavailable) >> >>open o_sync, write 6.270724 >> >>write, fdatasync

Re: [PERFORM] [HACKERS] fsync method checking

On 26 Mar, Manfred Spraul wrote: > [EMAIL PROTECTED] wrote: > >>Compare file sync methods with one 8k write: >>(o_dsync unavailable) >>open o_sync, write 6.270724 >>write, fdatasync13.275225 >>write, fsync, 13.359847 >> >> > Odd. Which fi

Re: [PERFORM] PostgreSQL and Linux 2.6 kernel.

r has an edge on the anticipatory scheduler. Depending on the current state of the AS scheduler, it can be within a few percent to 10% or so. I have some data with one of our tests here: http://developer.osdl.org/markw/fs/dbt2_project_results.html Mark ---(end of broa

Re: [PERFORM] backup/restore - another area.

ance. For anyone curious, I have some data on a 14-disk volume here: http://developer.osdl.org/markw/lvm/results.4/log/ and a 52-disk volume here: http://developer.osdl.org/markw/lvm/results.5/data/ Mark >Jeff <[EMAIL PROTECTED]> writes: > > Idea #1: &g

[PERFORM] analyzing postgresql performance for dbt-2

the database, where increasing the load increases the area of the database touched in addition to increasing the transaction rate. The overall metric increases somewhat, but the response time for most of the interactions also increases significantly: http://developer.osdl.org/markw/dbt2-pgsql/158/ [baselin

Re: [PERFORM] analyzing postgresql performance for dbt-2

e. The overall >> > > metric increases somewhat, but the response time for most of the >> > > interactions also increases significantly: >> > > >> > > http://developer.osdl.org/markw/dbt2-pgsql/158/ [baseline] >> > > - load of 100

Re: [PERFORM] analyzing postgresql performance for dbt-2

I've done a better controlled series of tests where I restore the database before each test and have grabbed sar and oprofile data: http://developer.osdl.org/markw/dbt2-pgsql/176/ - load of 100 warehouses - metric 1234.52 http://developer.osdl.org/markw/dbt2-pgsq

Re: [PERFORM] High Performance/High Reliability File system on

#x27;ll find the results interesting: http://developer.osdl.org/markw/fs/project_results.html Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] 7.3 vs 7.4 performance

I have some results with our DBT-2 (OLTP) workload on various linux-2.6 filesystems, if you'll find that interesting: http://developer.osdl.org/markw/fs/dbt2_project_results.html I've found JFS to perform similarly to ext2. Reiserfs isn't far behind. XFS and ext3 fall of