Re: [PERFORM] why does swap not recover?

2010-03-26 Thread Craig James
On 3/26/10 4:57 PM, Richard Yen wrote: Hi everyone, We've recently encountered some swapping issues on our CentOS 64GB Nehalem machine, running postgres 8.4.2. Unfortunately, I was foolish enough to set shared_buffers to 40GB. I was wondering if anyone would have any insight into why the sw

Re: [PERFORM] why does swap not recover?

2010-03-26 Thread Scott Carey
On Mar 26, 2010, at 4:57 PM, Richard Yen wrote: > Hi everyone, > > We've recently encountered some swapping issues on our CentOS 64GB Nehalem > machine, running postgres 8.4.2. Unfortunately, I was foolish enough to set > shared_buffers to 40GB. I was wondering if anyone would have any insigh

Re: [PERFORM] Block at a time ...

2010-03-26 Thread Scott Carey
On Mar 22, 2010, at 4:46 PM, Craig James wrote: > On 3/22/10 11:47 AM, Scott Carey wrote: >> >> On Mar 17, 2010, at 9:41 AM, Craig James wrote: >> >>> On 3/17/10 2:52 AM, Greg Stark wrote: On Wed, Mar 17, 2010 at 7:32 AM, Pierre C wrote: >> I was thinking in something like that, exce

Re: [PERFORM] pg_dump far too slow

2010-03-26 Thread Scott Carey
On Mar 21, 2010, at 8:50 AM, David Newall wrote: > Tom Lane wrote: >> I would bet that the reason for the slow throughput is that gzip >> is fruitlessly searching for compressible sequences. It won't find many. >> > > > Indeed, I didn't expect much reduction in size, but I also didn't expect

Re: [PERFORM] why does swap not recover?

2010-03-26 Thread Scott Marlowe
On Fri, Mar 26, 2010 at 5:57 PM, Richard Yen wrote: > Hi everyone, > > We've recently encountered some swapping issues on our CentOS 64GB Nehalem What version Centos? How up to date is it? Are there any other settings that aren't defaults in things like /etc/sysctl.conf? -- Sent via pgsql-per

[PERFORM] why does swap not recover?

2010-03-26 Thread Richard Yen
Hi everyone, We've recently encountered some swapping issues on our CentOS 64GB Nehalem machine, running postgres 8.4.2. Unfortunately, I was foolish enough to set shared_buffers to 40GB. I was wondering if anyone would have any insight into why the swapping suddenly starts, but never recover

Re: [PERFORM] Why Wal_buffer is 64KB

2010-03-26 Thread Scott Marlowe
On Fri, Mar 26, 2010 at 7:43 AM, Pierre C wrote: > >> After fsync/syncronous_commit off > > Do not use fsync off, it is not safe. Who cares about the performance of > fsync=off, when in practice you'd never use it with real data. > synchronnous_commit=off is fine for some applications, though. Th

Re: [PERFORM] Why Wal_buffer is 64KB

2010-03-26 Thread Pierre C
After fsync/syncronous_commit off Do not use fsync off, it is not safe. Who cares about the performance of fsync=off, when in practice you'd never use it with real data. synchronnous_commit=off is fine for some applications, though. More info is needed about your configuration (hardware, d

Re: [PERFORM] Performance Tuning Large PL/PGSQL Stored Procedure

2010-03-26 Thread Richard Huxton
On 26/03/10 03:56, Eliot Gable wrote: I really am chasing milliseconds here, and I appreciate all your feedback. You've given me a relatively large number of possible optimizations I can try out. I will definitely try out the libpqtypes. That sounds like a promising way to further cut down on ex

Re: [PERFORM] Performance Tuning Large PL/PGSQL Stored Procedure

2010-03-26 Thread Merlin Moncure
On Thu, Mar 25, 2010 at 11:56 PM, Eliot Gable wrote: >> >> How many rows min/max/avg are coming back in your refcursors?  Are you >> using cursors in order to return multiple complex data structures >> (sets, etc) in a single function call? >> > > I think the largest number of rows is around 40. M