| From: | David Lang <dlang(at)invendra(dot)net> |
|---|---|
| To: | Alan Stange <stange(at)rentec(dot)com> |
| Cc: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, Juan Casero <caseroj(at)comcast(dot)net>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL and Ultrasparc T1 |
| Date: | 2005-12-20 15:08:21 |
| Message-ID: | Pine.LNX.4.62.0512200706300.2807@qnivq.ynat.uz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, 20 Dec 2005, Alan Stange wrote:
> Jignesh K. Shah wrote:
>> I guess it depends on what you term as your metric for measurement.
>> If it is just one query execution time .. It may not be the best on
>> UltraSPARC T1.
>> But if you have more than 8 complex queries running simultaneously,
>> UltraSPARC T1 can do well compared comparatively provided the application
>> can scale also along with it.
>
> I just want to clarify one issue here. It's my understanding that the
> 8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu
> system by Solaris.
> So, one could have up to 32 postgresql processes running in parallel on the
> current systems (assuming the application can scale).
note that like hyperthreading, the strands aren't full processors, their
efficiancy depends on how much other threads shareing the core stall
waiting for external things.
David Lang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alan Stange | 2005-12-20 15:14:44 | Re: PostgreSQL and Ultrasparc T1 |
| Previous Message | Alan Stange | 2005-12-20 15:01:52 | Re: PostgreSQL and Ultrasparc T1 |