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, 28 Jul 2009, Doug Hunley wrote:
Jul 26 04:45:48 checkpoint complete: wrote 219 buffers (0.1%); 0
transaction log file(s) added, 0 removed, 0 recycled; write=43.634 s,
Each buffer is 8KB here. So this one, the largest of the checkpoints you
showed in your sample, is writing out 1.71M
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
I understand that checkpointing is a necessary part of a pgsql
database, but I am also under the impression that you want to find a
balance between how frequently you checkpoint and how much a given
checkpoint has to do. It's all about balancing the disk I/O out to get
a consistent throughput and f
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
Robert James wrote:
Thanks for the replies. I'm running Postgres 8.2 on Windows XP, Intel
Core Duo (though Postgres seems to use only one 1 core).
A single query can only use one core, but it will use both if multiple
queries come in.
The queries are self joins on very large tables, with l
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
Can you run those two queries with psql?
I remember having some trouble running multiple queries in the same pgadmin
process. Both would get stuck until both finished I think. I went to
running a pgadmin process per query.
On Tue, Jul 28, 2009 at 9:17 AM, Robert James wrote:
> Thanks for the r
Thanks for the replies. I'm running Postgres 8.2 on Windows XP, Intel Core
Duo (though Postgres seems to use only one 1 core).
The queries are self joins on very large tables, with lots of nested loops.
On Mon, Jul 27, 2009 at 9:40 PM, Tom Lane wrote:
> Chris writes:
> > Robert James wrote:
>
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
19 matches
Mail list logo
