On Thu, May 15, 2008 at 04:57:03PM -0400, Justin wrote:
> Isn't that the rub point in HT processor. A process running in HT
> virtual processor can lock up a specific chunk of the real processor up
> that would not normally be locked. So the process running in the Real
> processor gets blocke
Craig Ringer wrote:
Justin wrote:
[Since] PostgreSql is not multi-threaded but a single thread
application which spawns little exe's how is hyper threading
helping Postgresql at all ??
Multiple threads and multiple processes are two ways to tackle a
similar problem - that of how to do
Justin wrote:
[Since] PostgreSql is not multi-threaded but a single thread
application which spawns little exe's how is hyper threading helping
Postgresql at all ??
Multiple threads and multiple processes are two ways to tackle a similar
problem - that of how to do more than one thing on
On Thu, May 15, 2008 at 12:53 PM, Justin <[EMAIL PROTECTED]> wrote:
>
> Sense PostgreSql is not a multi-threaded but a single thread application
> which spawns little exe's how is hyper threading helping Postgresql at all
> ??
Two ways:
* The stats collector / autovacuum / bgwriter can operate
Tom Lane wrote:
Justin <[EMAIL PROTECTED]> writes:
From every thing i have read about Hyper Threading, it should be just
turned off.
Depends entirely on what you're doing. I usually leave it turned on
because compiling Postgres from source is measurably faster with it
than without i
Justin <[EMAIL PROTECTED]> writes:
> From every thing i have read about Hyper Threading, it should be just
> turned off.
Depends entirely on what you're doing. I usually leave it turned on
because compiling Postgres from source is measurably faster with it
than without it on my dual-Xeon box. I'
Scott Marlowe wrote:
On Thu, May 15, 2008 at 11:08 AM, Shane Ambler <[EMAIL PROTECTED]> wrote:
Semi Noob wrote:
My CPU is 2CPU: Intel(R) Xeon(TM) CPU 3.20GHz. Disk: disk system is
RAID-5;
Early versions of postgresql had issues with P4 HT CPU's but I believe they
have been re
On Thu, May 15, 2008 at 11:08 AM, Shane Ambler <[EMAIL PROTECTED]> wrote:
> Semi Noob wrote:
>
>> My CPU is 2CPU: Intel(R) Xeon(TM) CPU 3.20GHz. Disk: disk system is
>> RAID-5;
>
> Early versions of postgresql had issues with P4 HT CPU's but I believe they
> have been resolved.
>
> I am quite certa
Semi Noob wrote:
My CPU is 2CPU: Intel(R) Xeon(TM) CPU 3.20GHz. Disk: disk system is RAID-5;
Early versions of postgresql had issues with P4 HT CPU's but I believe
they have been resolved.
I am quite certain that it only related to the early P4's not the Xeon.
--
Shane Ambler
pgSQL (at
Pavan Deolasee wrote:
On Thu, May 15, 2008 at 3:48 PM, Semi Noob <[EMAIL PROTECTED]> wrote:
I set max_connections is 200.
What error message you get when you try with more than 64 clients ?
I have the max connection set 50. You want to be careful with this
setting if theres al
Thank you for your answer!
*"You did not give CPU and disk info. But still 57 seems a small number.
What I guess is you're running pgbench with scale factor 1 (since you
haven't mentioned scale factor) and that causes extreme contention for
smaller tables with large number of clients."*
My CPU is
On Thu, May 15, 2008 at 3:48 PM, Semi Noob <[EMAIL PROTECTED]> wrote:
>
>
> I set max_connections is 200.
What error message you get when you try with more than 64 clients ?
> 57 seems a small number, according to you, how much tps is normal or fast?
Its difficult to say how much is good. On my
On Tue, May 13, 2008 at 2:43 PM, Semi Noob <[EMAIL PROTECTED]> wrote:
> But after upgrade the max clients is
> also 64 (?!?) Is this the maximum clients support by program pgbench (my
> server on Linux ver8.2.5, pgbench on Windows - version postgresql is 8.3.1)?
> And the number 57 tps is fast?
>
13 matches
Mail list logo
