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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo