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
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
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
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
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, r.m.guerr...@usit.uio.no
Center for
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 use raid0?
On 5/12/09, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 12, 2009 at 1:00 PM, Dimitri dimitrik...@gmail.com 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
On Tuesday 12 May 2009 12:55:14 Scott Marlowe wrote:
On Tue, May 12, 2009 at 3:00 AM, Евгений Василев
evasi...@jarcomputers.com wrote:
I have the following table:
CREATE TABLE temp.tmp_135528
(
id integer NOT NULL,
prid integer,
group_id integer,
iinv integer,
oinv integer,
Hi Scott,
On 5/12/09, Scott Carey sc...@richrelevance.com 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
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
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
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
Greg Stark wrote:
On Mon, May 11, 2009 at 5:05 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
On Tue, May 12, 2009 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Matthew Wakeling matt...@flymine.org 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
On Mon, May 11, 2009 at 5:05 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
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
On 5/13/09 3:22 AM, Dimitri dimitrik...@gmail.com wrote:
Hi Scott,
On 5/12/09, Scott Carey sc...@richrelevance.com 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
On 5/12/09 10:06 PM, Scott Marlowe scott.marl...@gmail.com 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
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 pedantic
Dimitri dimitrik...@gmail.com 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
El Miércoles, 13 de Mayo de 2009 Tom Lane escribió:
Chris Browne cbbro...@acm.org 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
On 5/12/09 11:08 PM, Arjen van der Meijden acmmail...@tweakers.net
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.
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
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.
24 matches
Mail list logo
