Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread Heikki Linnakangas
Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: I think that changing the locking behavior is attacking the problem at the wrong level anyway. Right. By the time a patch here could have any effect, you've already lost the game --- having to deschedule and reschedule a process is a

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread Simon Riggs
On Wed, 2009-03-11 at 16:53 -0400, Jignesh K. Shah wrote: 1200: 2000: Medium Throughput: -1781969.000 Avg Medium Resp: 0.019 I think you need to iron out bugs in your test script before we put too much stock into the results generated. Your throughput should not be negative. I'd be interested

Re: [PERFORM] 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Fri, Mar 13, 2009 at 10:06 PM, Tom Lane t...@sss.pgh.pa.us wrote: I assume you meant effective_io_concurrency.  We'd still need a special case because the default is currently hard-wired at 1, not 0, if configure thinks the function exists. I

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: WALInsertLock is also quite high on Jignesh's list. That I've seen become the bottleneck on other tests too. Yeah, that's been seen to be an issue before. I had the germ of an idea about how to fix that: ... with no lock,

Re: [PERFORM] Query much slower when run from postgres function

2009-03-14 Thread decibel
On Mar 9, 2009, at 8:36 AM, Mario Splivalo wrote: Now, as I was explained on pg-jdbc mailinglist, that 'SET enable_seqscan TO false' affects all queries on that persistent connection from tomcat, and It's not good solution. So I wanted to post here to ask what other options do I have.

Re: [PERFORM] Query much slower when run from postgres function

2009-03-14 Thread decibel
On Mar 10, 2009, at 12:20 PM, Tom Lane wrote: f...@redhat.com (Frank Ch. Eigler) writes: For a prepared statement, could the planner produce *several* plans, if it guesses great sensitivity to the parameter values? Then it could choose amongst them at run time. We've discussed that in the

Re: [PERFORM] Query performance over a large proportion of data

2009-03-14 Thread decibel
On Mar 10, 2009, at 4:12 PM, Steve McLellan wrote: The server itself is a dual-core 3.7GHz Xeon Dell (each core reporting 2 logical CPUs) running an amd64 build of FreeBSD 6.2, and postgres 8.3.5 built from source. Uh, you're running an amd64 build on top of an Intel CPU? I didn't think

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread decibel
On Mar 11, 2009, at 10:48 PM, Jignesh K. Shah wrote: Fair enough.. Well I am now appealing to all who has a fairly decent sized hardware want to try it out and see whether there are gains, no-changes or regressions based on your workload. Also it will help if you report number of cpus

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread decibel
On Mar 12, 2009, at 2:22 PM, Jignesh K. Shah wrote: Something that might be useful for him to report is the avg number of active backends for each data point ... short of doing select * from pg_stat_activity and removing the IDLE entries, any other clean way to get that information. Uh,

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread decibel
On Mar 13, 2009, at 8:05 AM, Gregory Stark wrote: Jignesh K. Shah j.k.s...@sun.com writes: Scott Carey wrote: On 3/12/09 11:37 AM, Jignesh K. Shah j.k.s...@sun.com wrote: In general, I suggest that it is useful to run tests with a few different types of pacing. Zero delay pacing will not

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-14 Thread decibel
On Mar 13, 2009, at 3:02 PM, Jignesh K. Shah wrote: vmstat seems similar to wakeup some kthr memorypagedisk faults cpu r b w swap free re mf pi po fr de sr s0 s1 s2 sd in sy cs us sy id 63 0 0 45535728 38689856 0 14 0 0 0 0 0 0 0 0

Re: [PERFORM] Query performance over a large proportion of data

2009-03-14 Thread Matteo Beccati
decibel wrote: On Mar 10, 2009, at 4:12 PM, Steve McLellan wrote: The server itself is a dual-core 3.7GHz Xeon Dell (each core reporting 2 logical CPUs) running an amd64 build of FreeBSD 6.2, and postgres 8.3.5 built from source. Uh, you're running an amd64 build on top of an Intel CPU? I