[PERFORM] scheduler

2008-01-21 Thread Adrian Moisey
Hi Which scheduler is recommended for a box that is dedicated to running postgres? I've asked google and found no answers. -- Adrian Moisey System Administrator | CareerJunction | Your Future Starts Here. Web: www.careerjunction.co.za | Email: [EMAIL PROTECTED] Phone: +27 21 686 6820 | Mobile

Re: [PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Fernando Ike
Em Mon, 21 Jan 2008 15:45:54 -0800 Jeff Davis <[EMAIL PROTECTED]> escreveu: > On Mon, 2008-01-21 at 18:31 -0500, Greg Smith wrote: > > pgbench doesn't handle 100 clients at once very well on the same > > box as the server, unless you have a pretty serious system. The > > pgbench program itself ha

Re: [PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Greg Smith
On Mon, 21 Jan 2008, Jeff Davis wrote: He was referring to the CFQ I/O scheduler. I don't think that will affect pgbench itself, because it doesn't read/write to disk, right? It does if you are writing latency log files but it shouldn't be in the cases given. But there's something weird abou

Re: [PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Jeff Davis
On Mon, 2008-01-21 at 18:31 -0500, Greg Smith wrote: > pgbench doesn't handle 100 clients at once very well on the same box as > the server, unless you have a pretty serious system. The pgbench program > itself has a single process model that doesn't handle the CFQ round-robin > very well at al

Re: [PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Greg Smith
On Mon, 21 Jan 2008, Hannes Dorbath wrote: pgbench -i -s 10 -U pgsql -d bench && pgbench -t 1000 -c 100 -U pgsql -d bench pgbench doesn't handle 100 clients at once very well on the same box as the server, unless you have a pretty serious system. The pgbench program itself has a single proc

Re: [PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Jeff Davis
On Mon, 2008-01-21 at 22:55 +0100, Hannes Dorbath wrote: > I might completely misunderstand this feature. Shouldn't > "synchronous_commit = off" improve performance? > > Whatever I do, I find "synchronous_commit = off" to degrade performance. > > Especially it doesn't like the CFQ I/O scheduler

Re: [PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Pavel Stehule
Hello synchronous_commit = off is well for specific load, try only one connect pgbench ~ it is analogy for database import or some administrator's work. Regards Pavel Stehule On 21/01/2008, Hannes Dorbath <[EMAIL PROTECTED]> wrote: > I might completely misunderstand this feature. Shouldn't > "

[PERFORM] 8.3 synchronous_commit

2008-01-21 Thread Hannes Dorbath
I might completely misunderstand this feature. Shouldn't "synchronous_commit = off" improve performance? Whatever I do, I find "synchronous_commit = off" to degrade performance. Especially it doesn't like the CFQ I/O scheduler, it's not so bad with deadline. Synthetic load like pgbench -i -

Re: [PERFORM] strange pauses

2008-01-21 Thread Decibel!
On Jan 21, 2008, at 1:58 AM, Adrian Moisey wrote: Perhaps, if you want to avoid I/O caused by temp tables (but it's not at checkpoint time, so perhaps this has nothing to do with your problem), you could try raising temp_buffers. How can I find out if temp_buffers is being exceeded ? You

Re: [PERFORM] Slow performance with left outer join

2008-01-21 Thread Pavel Stehule
Hello > > Filter: ((COALESCE((at_type)::integer, 1) = 1) AND > > (COALESCE(at_language, 0::numeric) = 0::numeric)) > > If this is slow, it must be that the scan of fpuarticletext actually > returns many more rows than the single row the planner is expecting. > The reason the estimat

Re: [PERFORM] Slow performance with left outer join

2008-01-21 Thread Tom Lane
"Marten Verhoeven" <[EMAIL PROTECTED]> writes: > This is the query analysis: > Nested Loop Left Join (cost=1796.69..3327.98 rows=5587 width=516) > Join Filter: (fpuarticle.a_no = fpuarticletext.at_a_no) > Filter: (strpos(lowerCOALESCE(fpuarticle.a_code, ''::character > varying))::text |

Re: [PERFORM] Slow performance with left outer join

2008-01-21 Thread Pavel Stehule
Hello please, send output EXPLAIN ANALYZE statement Regards Pavel Stehule On 21/01/2008, Marten Verhoeven <[EMAIL PROTECTED]> wrote: > > > Hi, > > Since I moved from PostgreSQL 7.3 to 8.2 I have a query which suddenly runs > very slow. In 7.3 it was really fast. It seems that the query analyser

[PERFORM] Slow performance with left outer join

2008-01-21 Thread Marten Verhoeven
Hi, Since I moved from PostgreSQL 7.3 to 8.2 I have a query which suddenly runs very slow. In 7.3 it was really fast. It seems that the query analyser makes other choices, which I don't understand. I have the query: SELECT * FROM fpuArticle LEFT OUTER JOIN fpuArticleText ON a_No=at_a_N

Re: [PERFORM] strange pauses

2008-01-21 Thread Adrian Moisey
Hi Perhaps, if you want to avoid I/O caused by temp tables (but it's not at checkpoint time, so perhaps this has nothing to do with your problem), you could try raising temp_buffers. How can I find out if temp_buffers is being exceeded ? -- Adrian Moisey System Administrator | CareerJunction