From: | Arjen van der Meijden <acmmailing(at)tweakers(dot)net> |
---|---|
To: | Markus Schaber <schabi(at)logix-tt(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL scalability on Sun UltraSparc T1 |
Date: | 2006-08-07 13:45:08 |
Message-ID: | 44D743E4.6050109@tweakers.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Markus,
As said, our environment really was a read-mostly one. So we didn't do
much inserts/updates and thus spent no time tuning those values and left
them as default settings.
Best regards,
Arjen
Markus Schaber wrote:
> Hi, Arjen,
>
> Arjen van der Meijden wrote:
>
>> It was the 8core version with 16GB memory... but actually that's just
>> overkill, the active portions of the database easily fits in 8GB and a
>> test on another machine with just 2GB didn't even show that much
>> improvements when going to 7GB (6x1G, 2x 512M), it was mostly in the
>> range of 10% improvement or less.
>
> I'd be interested in the commit_siblings and commit_delay settings,
> tuning them could give a high increase on throughput for highly
> concurrent insert/update workloads, at the cost of latency (and thus
> worse results for low concurrency situations).
>
> Different fsync method settings can also make a difference (I presume
> that syncing was enabled).
>
> HTH,
> Markus
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Saranya Sivakumar | 2006-08-07 15:35:02 | Re: [PERFORM] 7.3.2 pg_restore very slow |
Previous Message | Markus Schaber | 2006-08-07 13:32:39 | Re: sub select performance due to seq scans |