Re: [PERFORM] [HACKERS] fsync vs open_sync

2004-08-10 Thread pgsql
>> Anyway, with fsync enabled using standard fsync(), I get roughly > 300-400 >> inserts per second. With fsync disabled, I get about 7000 inserts per >> second. When I re-enable fsync but use the open_sync option, I can get >> about 2500 inserts per second. > > You are getting 300-400 inserts/sec

Re: [PERFORM] [HACKERS] fsync vs open_sync

2004-08-13 Thread pgsql
> Guys, just so you know: > > OSDL did some testing and found Ext3 to be perhaps the worst FS for > PostgreSQL > -- although this testing was with the default options. Ext3 involved an > almost 40% write performance penalty compared with Ext2, whereas the > penalty > for ReiserFS and JFS was less

Re: [PERFORM] fsync vs open_sync

2004-08-13 Thread pgsql
>> OSDL did some testing and found Ext3 to be perhaps the worst FS for >> PostgreSQL >> -- although this testing was with the default options. Ext3 involved > an >> almost 40% write performance penalty compared with Ext2, whereas the >> penalty >> for ReiserFS and JFS was less than 10%. >> >> Thi

Re: [PERFORM] Performance advice

2003-06-25 Thread pgsql
On Wed, 25 Jun 2003, Achilleus Mantzios wrote: > What i think would be ideal (helpful/feasible) > is some kind of documentation of the algorithms involved > in the planner/optimizer, along with some pointers > to postgresql.conf parameters where applicable. > > This way we will know > - Why somet

[PERFORM] tsearch2 headline and postgresql.conf

2006-01-21 Thread pgsql-performance
Hi folks, I'm not sure if this is the right place for this but thought I'd ask. I'm relateively new to postgres having only used it on 3 projects and am just delving into the setup and admin for the second time. I decided to try tsearch2 for this project's search requirements but am having

Re: [PERFORM] tsearch2 headline and postgresql.conf

2006-01-22 Thread pgsql-performance
Oleg Bartunov wrote: You didn't provides us any query with explain analyze. Just to make sure you're fine. Oleg On Sun, 22 Jan 2006, [EMAIL PROTECTED] wrote: Hi folks, I'm not sure if this is the right place for this but thought I'd ask. I'm relateively new to postgres having only used

[PERFORM] Why do my hash joins turn to nested loops?

2008-08-21 Thread pgsql-performance
09 width=8) (actual time=0.009..7.996 rows=8172 loops=3555) Filter: (specs_sort.spec_uid = 4) -> Index Scan using type_pkey on type (cost=0.00..0.27 rows=1 width=4) (actual time=0.010..0.011 rows=1 loops=3555) Index Cond: ((logical.typ

Re: [PERFORM] Why do my hash joins turn to nested loops?

2008-08-22 Thread pgsql-performance
s good timing. Thanks! -- Ian Smith www.ian.org -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread pgsql-performance
In message <[EMAIL PROTECTED]>, Jeff writes: I'll go run the regression test suite with my gcc -O2 pg and the suncc pg. See if they pass the test. My default set of gcc optimization flags is: -O3 -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions -mcpu=i686 -march