On Tue, Jul 28, 2009 at 7:21 PM, Greg Smith wrote:
> On Tue, 28 Jul 2009, Scott Marlowe wrote:
>
>> Just FYI, I ran the same basic test but with -c 10 since -c shouldn't
>> really be greater than -s
>
> That's only true if you're running the TPC-B-like or other write tests,
> where access to the sm
On Tue, 28 Jul 2009, Dave Youatt wrote:
Unlikely. Different threads on the same CPU core share their resources, so they
don't
need an explicit communication channel at all (I'm simplifying massively here).
A real
interconnect is only needed between CPUs and between different cores on a CPU,
an
On Tue, 28 Jul 2009, Scott Carey wrote:
On 7/28/09 1:28 PM, "Greg Smith" wrote:
On Tue, 28 Jul 2009, Matthew Wakeling wrote:
Unlikely. Different threads on the same CPU core share their resources, so
they don't need an explicit communication channel at all (I'm simplifying
massively here). A
On Wed, 29 Jul 2009, Stefan Kaltenbrunner wrote:
oh - the 90k tps are with the new multithreaded pgbench? missed that fact. As
you can see from my results I managed to get 83k with the 8.4 pgbench on a
slightly slower Nehalem which does not sound too impressive for the new
code...
I got 96K
Greg Smith wrote:
On Wed, 29 Jul 2009, Stefan Kaltenbrunner wrote:
Well the real problem is that pgbench itself does not scale too well
to lots of concurrent connections and/or to high transaction rates so
it seriously skews the result.
Sure, but that's what the multi-threaded pgbench code a
On Wed, 29 Jul 2009, Stefan Kaltenbrunner wrote:
Well the real problem is that pgbench itself does not scale too well to lots
of concurrent connections and/or to high transaction rates so it seriously
skews the result.
Sure, but that's what the multi-threaded pgbench code aims to fix, which
Greg Smith wrote:
On Tue, 28 Jul 2009, Scott Marlowe wrote:
Just FYI, I ran the same basic test but with -c 10 since -c shouldn't
really be greater than -s
That's only true if you're running the TPC-B-like or other write tests,
where access to the small branches table becomes a serious hotsp
On Tue, Jul 28, 2009 at 4:11 PM, Scott Marlowe wrote:
> On Tue, Jul 28, 2009 at 2:58 PM, Merlin Moncure wrote:
>> On Mon, Jul 27, 2009 at 2:05 PM, Dave Youatt wrote:
>>> On 01/-10/-28163 11:59 AM, Greg Smith wrote:
On Tue, 21 Jul 2009, Doug Hunley wrote:
> Just wondering is the issue
On Tue, Jul 28, 2009 at 5:21 PM, Greg Smith wrote:
> On Tue, 28 Jul 2009, Scott Marlowe wrote:
>
>> Just FYI, I ran the same basic test but with -c 10 since -c shouldn't
>> really be greater than -s
>
> That's only true if you're running the TPC-B-like or other write tests,
> where access to the sm
On Tue, 28 Jul 2009, Scott Marlowe wrote:
Just FYI, I ran the same basic test but with -c 10 since -c shouldn't
really be greater than -s
That's only true if you're running the TPC-B-like or other write tests,
where access to the small branches table becomes a serious hotspot for
contention.
On 7/28/09 1:58 PM, "Merlin Moncure" wrote:
> On Mon, Jul 27, 2009 at 2:05 PM, Dave Youatt wrote:
>> On 01/-10/-28163 11:59 AM, Greg Smith wrote:
>>> On Tue, 21 Jul 2009, Doug Hunley wrote:
>>>
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/
On 7/28/09 1:28 PM, "Greg Smith" wrote:
> On Tue, 28 Jul 2009, Matthew Wakeling wrote:
>
>> Unlikely. Different threads on the same CPU core share their resources, so
>> they don't need an explicit communication channel at all (I'm simplifying
>> massively here). A real interconnect is only nee
On Tue, Jul 28, 2009 at 2:58 PM, Merlin Moncure wrote:
> On Mon, Jul 27, 2009 at 2:05 PM, Dave Youatt wrote:
>> On 01/-10/-28163 11:59 AM, Greg Smith wrote:
>>> On Tue, 21 Jul 2009, Doug Hunley wrote:
>>>
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-perfo
On Mon, Jul 27, 2009 at 2:05 PM, Dave Youatt wrote:
> On 01/-10/-28163 11:59 AM, Greg Smith wrote:
>> On Tue, 21 Jul 2009, Doug Hunley wrote:
>>
>>> Just wondering is the issue referenced in
>>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>>> is still present in 8.4 or if
On Tue, 28 Jul 2009, Matthew Wakeling wrote:
Unlikely. Different threads on the same CPU core share their resources, so
they don't need an explicit communication channel at all (I'm simplifying
massively here). A real interconnect is only needed between CPUs and between
different cores on a CP
* *Message-id*:
http://archives.postgresql.org/pgsql-performance/2009-07/msg00293.php>>
On Mon, 27 Jul 2009, Dave Youatt wrote:
Greg, those are compelling numbers for the new Nehalem processors.
Great news
On Mon, 27 Jul 2009, Dave Youatt wrote:
Greg, those are compelling numbers for the new Nehalem processors.
Great news for postgresql. Do you think it's due to the new internal
interconnect...
Unlikely. Different threads on the same CPU core share their resources, so
they don't need an explici
On 7/27/09 11:05 AM, "Dave Youatt" wrote:
> On 01/-10/-28163 11:59 AM, Greg Smith wrote:
>> On Tue, 21 Jul 2009, Doug Hunley wrote:
>>
> Also, and this is getting maybe too far off topic, beyond the buzzwords,
> what IS the new "hyperthreading" in Nehalems? -- opportunistic
> superpipelined c
On 01/-10/-28163 11:59 AM, Greg Smith wrote:
> On Tue, 21 Jul 2009, Doug Hunley wrote:
>
>> Just wondering is the issue referenced in
>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>> is still present in 8.4 or if some tunable (or other) made the use of
>> hyperthreading a
On Mon, 27 Jul 2009, Dave Youatt wrote:
Do you think it's due to the new internal interconnect, that bears a
strong resemblance to AMD's hypertransport (AMD's buzzword for borrowing
lots of interconnect technology from the DEC alpha (EV7?)), or Intel
fixing a not-so-good initial implementation
On Tue, 21 Jul 2009, Doug Hunley wrote:
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
is still present in 8.4 or if some tunable (or other) made the use of
hyperthreading a non-issue. We're looking to upgrade our servers soon
for
Scott Carey wrote:
But back on topic for HT -- HT doesn't like spin-locks much unless they
use the right low level instruction sequence rather than actually
spinning. With the right instruction, the spin will allow the other
thread to do work... With the wrong one, it will tie up the pipeline.
On 7/21/09 9:22 AM, "Scott Marlowe" wrote:
>> But, the real point is that "thread" (whether "CoolThread" or "HT" thread),
>> is not the same as core, which is not the same as processor. X 2 threads is
>> usually significantly less benefit than X 2 cores. X 2 cores is probably
>> less benefit t
2009/7/21 Mark Mielke :
> On 07/21/2009 10:36 AM, Grzegorz Jaśkiewicz wrote:
>
> On Tue, Jul 21, 2009 at 3:16 PM, Scott Marlowe
> wrote:
>
>
> On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
>
>
> Just wondering is the issue referenced in
> http://archives.postgresql.org/pgsql-performance/2005-
On 07/21/2009 10:36 AM, Grzegorz Jaśkiewicz wrote:
On Tue, Jul 21, 2009 at 3:16 PM, Scott Marlowe wrote:
On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
is still prese
On Tue, Jul 21, 2009 at 3:16 PM, Scott Marlowe wrote:
> On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
>> Just wondering is the issue referenced in
>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>> is still present in 8.4 or if some tunable (or other) made the use of
2009/7/21 Grzegorz Jaśkiewicz :
> On Tue, Jul 21, 2009 at 1:42 PM, Doug Hunley wrote:
>> Just wondering is the issue referenced in
>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>> is still present in 8.4 or if some tunable (or other) made the use of
>> hyperthreading a no
On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
> Just wondering is the issue referenced in
> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
> is still present in 8.4 or if some tunable (or other) made the use of
> hyperthreading a non-issue. We're looking to upgrade our
On Tue, Jul 21, 2009 at 1:42 PM, Doug Hunley wrote:
> Just wondering is the issue referenced in
> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
> is still present in 8.4 or if some tunable (or other) made the use of
> hyperthreading a non-issue. We're looking to upgrade our
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
is still present in 8.4 or if some tunable (or other) made the use of
hyperthreading a non-issue. We're looking to upgrade our servers soon
for performance reasons and am trying to determ
30 matches
Mail list logo
