Re: [PERFORM] bad performance on Solaris 10

2006-04-04 Thread Josh Berkus
Mark, I suspect that making a *separate* filesystem for the pg_xlog directory and mounting that logging + forcedirectio would be a nice way to also get performance while keeping the advantages of logging + file buffercache for the *rest* of the postgres components. Cheers Yes, we tested

Re: [PERFORM] freebsd/softupdates for data dir

2006-04-04 Thread Vivek Khera
On Apr 3, 2006, at 10:10 PM, Mark Kirkwood wrote: I've always left them on, and never had any issues...(even after unscheduled power loss - which happened here yesterday). As I understand it, the softupdate code reorders *metadata* operations, and does not alter data operations - so the

[PERFORM] vacuum full seems to hang on very small table

2006-04-04 Thread Dan Harris
I have a table with 1 live row that I found has 115000 dead rows in it ( from a testing run ). I'm trying to VACUUM FULL the table and it has run for over 18 hours without completion. Considering the hardware on this box and the fact that performance seems reasonable in all other aspects,

Re: [PERFORM] vacuum full seems to hang on very small table

2006-04-04 Thread Brad Nicholson
Dan Harris wrote: I have a table with 1 live row that I found has 115000 dead rows in it ( from a testing run ). I'm trying to VACUUM FULL the table and it has run for over 18 hours without completion. Considering the hardware on this box and the fact that performance seems reasonable in all

Re: [PERFORM] vacuum full seems to hang on very small table

2006-04-04 Thread Simon Riggs
On Tue, 2006-04-04 at 08:59 -0600, Dan Harris wrote: I have a table with 1 live row that I found has 115000 dead rows in it ( from a testing run ). I'm trying to VACUUM FULL the table and it has run for over 18 hours without completion. Considering the hardware on this box and the fact

Re: [PERFORM] The order of fields around the = in the WHERE

2006-04-04 Thread Mike Quinn
The datatype of the join columns is a user defined type and there are no commutators defined. I will fix that and retest. Thanks for the insight. Mike Quinn ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ?

[PERFORM] Query runs too long for indexed tables

2006-04-04 Thread Andrus
I have relatively small tables (toode and rid) in fast server. Both tables are indexed on toode field. Following query takes long time to run. toode field type is char(20). It is difficult to change this field type. Any idea how to speed up this query ? UPDATE firma1.rid SET toode=NULL

Re: [PERFORM] Query runs too long for indexed tables

2006-04-04 Thread Scott Marlowe
On Tue, 2006-04-04 at 14:37, Andrus wrote: I have relatively small tables (toode and rid) in fast server. Both tables are indexed on toode field. Following query takes long time to run. toode field type is char(20). It is difficult to change this field type. Any idea how to speed up this

Re: [PERFORM] Query runs too long for indexed tables

2006-04-04 Thread Marc Morin
Wondering if Update firma1.rid set toode=null where toode is not null and not exists(select 1 from firma1.toode where toode=rid.toode); Would be faster... Problem appears to be the seqscan of seqscan... No? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On

Re: [PERFORM] Query runs too long for indexed tables

2006-04-04 Thread Marc Morin
Explain analyze would be nice ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrus Sent: Tuesday, April 04, 2006 3:37 PM To: pgsql-performance@postgresql.org Subject: [PERFORM] Query runs too long for indexed tables I have relatively

Re: [PERFORM] Query using SeqScan instead of IndexScan

2006-04-04 Thread Jim Nasby
On Apr 2, 2006, at 6:30 PM, Josh Berkus wrote: But just as a follow up question to your #1 suggestion, I have 8 GB of ram in my production server. You're saying to set the effective_cache_size then to 5 GB roughly? Somewhere around 655360? Currently it is set to 65535. Is that something that's

Re: [PERFORM] Query using SeqScan instead of IndexScan

2006-04-04 Thread Jim Nasby
On Apr 1, 2006, at 12:51 PM, Brendan Duddridge wrote: from SELECT * FROM pg_stats WHERE tablename='table' AND attname='category_id' I find correlation on category_product for category_id is 0.643703 Would setting the index on category_id to be clustered help with this? It would absolutely

Re: [PERFORM] The order of fields around the = in the WHERE

2006-04-04 Thread Mike Quinn
version PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.6 (1 row) -- After commutator added to operators of user defined type, -- the