On Wed, 13 May 2009, Scott Carey wrote:
Can you do a quick and dirty memory bandwidth test? (assuming linux)
/sbin/hdparm -T /dev/sd
...its not a very accurate measurement, but its quick and highlights
relative hardware differences very easily.
I've found "hdparm -T" to be useful for compar
-Original Message-
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- A
much
>> better index to answer your query is (city_id, house_id, floor_id) -
>> then it can just look up straight away. Instead of the index returning
>> 20 rows to check, it will return ju
On 13-5-2009 20:39 Scott Carey wrote:
Excellent! That is a pretty huge boost. I'm curious which aspects of this
new architecture helped the most. For Postgres, the following would seem
the most relevant:
1. Shared L3 cache per processors -- more efficient shared datastructure
access.
2. Fas
Hi,
Le 13 mai 09 à 18:42, Scott Carey a écrit :
will not help, as each client is *not* disconnecting/reconnecting
during the test, as well PG is keeping well even 256 users. And TPS
limit is reached already on 64 users, don't think pooler will help
here.
Actually, it might help a little. Post
Matthew Wakeling wrote:
Thomas, the order of columns in the index matters. The index is
basically a tree structure, which resolves the left-most column before
resolving the column to the right of it. So to answer your query, it
will resolve the city_id, then it will have to scan almost all of t
FYI:
This is an excellent article on the Nehalem CPU's and their memory
performance as the CPU and RAM combinations change:
http://blogs.sun.com/jnerl/entry/configuring_and_optimizing_intel_xeon
Its fairly complicated (as it is for the Opteron too).
On 5/13/09 9:58 AM, "Scott Carey" wrote:
>
On 5/12/09 11:08 PM, "Arjen van der Meijden"
wrote:
> We have a dual E5540 with 16GB (I think 1066Mhz) memory here, but no AMD
> Shanghai. We haven't done PostgreSQL benchmarks yet, but given the
> previous experiences, PostgreSQL should be equally faster compared to mysql.
>
> Our databasebenc
El Miércoles, 13 de Mayo de 2009 Tom Lane escribió:
> Chris Browne writes:
> > cl...@uah.es (Angel Alvarez) writes:
> >> there is not so 'more optimal' thing but a simple 'better' thing.
>
> > If I wanted to be pedantic about it, I'd say that the word "nearly" is
> > missing.
>
> > That is, it
Chris Browne writes:
> cl...@uah.es (Angel Alvarez) writes:
>> there is not so 'more optimal' thing but a simple 'better' thing.
> If I wanted to be pedantic about it, I'd say that the word "nearly" is
> missing.
> That is, it would be "strictly correct" if one instead said "more
> nearly optim
Dimitri wrote:
> The idea is good, but *only* pooling will be not enough. I mean if
> all what pooler is doing is only keeping no more than N backends
> working - it'll be not enough. You never know what exactly your
> query will do - if you choose your N value to be sure to not
> overload CPU an
cl...@uah.es (Angel Alvarez) writes:
> more optimal plan...
> morreoptimal configuration...
>
> we suffer a 'more optimal' superlative missuse
>
> there is not so 'more optimal' thing but a simple 'better' thing.
>
> im not native english speaker but i think it still applies.
If I wanted to be p
On 5/12/09 10:06 PM, "Scott Marlowe" wrote:
> Just realized I made a mistake, I was under the impression that
> Shanghai CPUs had 8xxx numbers while barcelona had 23xx numbers. I
> was wrong, it appears the 8xxx numbers are for 4+ socket servers while
> the 23xx numbers are for 2 or fewer sock
On 5/13/09 3:22 AM, "Dimitri" wrote:
> Hi Scott,
>
> On 5/12/09, Scott Carey wrote:
>> Although nobody wants to support it, he should try the patch that Jignesh K.
>> Shah (from Sun) proposed that makes ProcArrayLock lighter-weight. If it
>> makes 32 cores much faster, then we have a smoking
The idea is good, but *only* pooling will be not enough. I mean if all
what pooler is doing is only keeping no more than N backends working -
it'll be not enough. You never know what exactly your query will do -
if you choose your N value to be sure to not overload CPU and then
some of your queries
On Mon, May 11, 2009 at 5:05 PM, Stefan Kaltenbrunner
wrote:
>> Good to know!!! I imagine that on a PS3 it would be _really_ fast... :-)
>
> well not really - while it is fairly easy to get postgresql running on a PS3
> it is not a fast platform. While the main CPU there is a pretty fast Power
> b
Glenn Maynard wrote:
> I'm sorry, but I'm confused. Everyone keeps talking about
> connection pooling, but Dimitri has said repeatedly that each client
> makes a single connection and then keeps it open until the end of
> the test, not that it makes a single connection per SQL query.
> Connecti
On Tue, May 12, 2009 at 11:18 AM, Tom Lane wrote:
> Matthew Wakeling writes:
>> On Tue, 12 May 2009, Simon Riggs wrote:
>>> No, we spawn then authenticate.
>
>> But you still have a single thread doing the accept() and spawn. At some
>> point (maybe not now, but in the future) this could become a
Greg Stark wrote:
On Mon, May 11, 2009 at 5:05 PM, Stefan Kaltenbrunner
wrote:
Good to know!!! I imagine that on a PS3 it would be _really_ fast... :-)
well not really - while it is fairly easy to get postgresql running on a PS3
it is not a fast platform. While the main CPU there is a pretty f
On Tue, 12 May 2009, Greg Smith wrote:
You should test what happens if you reduce the index to just being
(city_id,street_id).
I think you're missing the point a little here. The point is that Thomas
is creating an index on (city_id, street_id, house_id, floor_id) and
running a query on (city
On MySQL there is no changes if I set the number of sessions in the
config file to 400 or to 2000 - for 2000 it'll just allocate more
memory.
After latest fix with default_statistics_target=5, version 8.3.7 is
running as fast as 8.4, even 8.4 is little little bit slower.
I understand your positio
I'm also confused, but seems discussion giving also other ideas :-)
But yes, each client is connecting to the database server only *once*.
To presice how the test is running:
- 1 client is started => 1 in total
- sleep ...
- 1 another client is started => 2 in total
- sleep ..
- 2 another c
Hi Scott,
On 5/12/09, Scott Carey wrote:
> Although nobody wants to support it, he should try the patch that Jignesh K.
> Shah (from Sun) proposed that makes ProcArrayLock lighter-weight. If it
> makes 32 cores much faster, then we have a smoking gun.
>
> Although everyone here is talking about
On Tuesday 12 May 2009 12:55:14 Scott Marlowe wrote:
> On Tue, May 12, 2009 at 3:00 AM, Евгений Василев
>
> wrote:
> > I have the following table:
> >
> > CREATE TABLE "temp".tmp_135528
> > (
> > id integer NOT NULL,
> > prid integer,
> > group_id integer,
> > iinv integer,
> > oinv integer,
> > i
On 5/12/09, Robert Haas wrote:
> On Tue, May 12, 2009 at 1:00 PM, Dimitri wrote:
>> On MySQL there is no changes if I set the number of sessions in the
>> config file to 400 or to 2000 - for 2000 it'll just allocate more
>> memory.
>
> I don't care whether the setting affects the speed of MySQL.
Dont worry about it, this is just for performance testing.
thomas
> Thomas Finneid wrote:
>> Hi
>>
>> I am wondering what stripe size, on a raid 0, is the most suitable for
>> postgres 8.2?
>>
>
> Hello
>
> Raid 0 for a database? This is a disaster waiting to happen.
> Are you sure you want to u
Thomas Finneid wrote:
> Hi
>
> I am wondering what stripe size, on a raid 0, is the most suitable for
> postgres 8.2?
>
Hello
Raid 0 for a database? This is a disaster waiting to happen.
Are you sure you want to use raid0?
regards
--
Rafael Martinez,
Center for Information Technology Servi
We have a dual E5540 with 16GB (I think 1066Mhz) memory here, but no AMD
Shanghai. We haven't done PostgreSQL benchmarks yet, but given the
previous experiences, PostgreSQL should be equally faster compared to mysql.
Our databasebenchmark is actually mostly a cpu/memory-benchmark.
Comparing th
Just realized I made a mistake, I was under the impression that
Shanghai CPUs had 8xxx numbers while barcelona had 23xx numbers. I
was wrong, it appears the 8xxx numbers are for 4+ socket servers while
the 23xx numbers are for 2 or fewer sockets. So, there are several
quite affordable shanghai cp
On Wed, May 13, 2009 at 1:51 AM, Thomas Finneid wrote:
> Hi
>
> I am wondering what stripe size, on a raid 0, is the most suitable for
> postgres 8.2?
>
> I read a performance tutorial by Bruce Momjian and it suggest setting the
> stripe size to the same block size (as pg uses?)
> ( http://momjian
First off, is there a way to pre-filter some of this data, by a view,
temporary table, partitioned indexes or something.
Secondly, one of the problems seems to be the size of the data and its
index, how can I calulate how much space a particular part of the index
needs in memory? maybe I co
Hi
I am wondering what stripe size, on a raid 0, is the most suitable for
postgres 8.2?
I read a performance tutorial by Bruce Momjian and it suggest setting
the stripe size to the same block size (as pg uses?)
( http://momjian.us/main/writings/pgsql/hw_performance/index.html )
But I want to
31 matches
Mail list logo
