Hi
John A Meinel wrote:
bm\mbn wrote:
Hi Everyone
The machine is IBM x345 with ServeRAID 6i 128mb cache and 6 SCSI 15k
disks.
2 disks are in RAID1 and hold the OS, SWAP pg_xlog
4 disks are in RAID10 and hold the Cluster itself.
the DB will have two major tables 1 with 10 million rows
On Tue, Sep 20, 2005 at 10:51:41AM +0300, Michael Ben-Nes wrote:
I must admit im a bit amazed how such important parameter is so
ambiguous. an optimal strip size can improve the performance of the db
significantly.
It's configuration dependent. IME, it has an insignificant effect. If
Hi Everybody!
I've got a spare machine which is 2xXEON 3.2GHz, 4Gb RAM
14x140Gb SCSI 10k (LSI MegaRaid 320U). It is going into production in 3-5months.
I do have free time to run tests on this machine, and I could test different
stripe sizes
if somebody prepares a test script and data for that.
unsubscribe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Typically your stripe size impacts read and write.
In Solaris, the trick is to match it with your maxcontig parameter. If
you set maxcontig to 128 pages which is 128* 8 = 1024k (1M) then your
optimal stripe size is 128 * 8 / (number of spindles in LUN).. Assuming
number of spindles is 6 then
I have benched different sripe sizes with different file systems, and the perfmance differences can be quite dramatic.
Theoreticaly a smaller stripe is better for OLTP as you can write more
small transactions independantly to more different disks more often
than not, but a large stripe size is
Alex Turner wrote:
I would also recommend looking at file system. For us JFS worked
signifcantly
faster than resier for large read loads and large write loads, so we chose
JFS
over ext3 and reiser.
has jfs been reliable for you? there seems to be a lot of conjecture about
I have found JFS to be just fine. We have been running a medium
load on this server for 9 months with no unscheduled down time.
Datbase is about 30gig on disk, and we get about 3-4 requests per
second that generate results sets in the thousands from about 8am to
about 11pm.
I have foudn that JFS
I have found that while the OS may flush to the controller fast with
fsync=true, the controller does as it pleases (it has BBU, so I'm not
too worried), so you get great performance because your controller is
determine read/write sequence outside of what is being demanded by an
fsync.
Alex Turner
Hi Everybody.
I am going to replace some 'select count(*) from ... where ...' queries
which run on large tables (10M+ rows) with something like
'explain select * from ... where ' and parse planner output after that
to find out its forecast about number of rows the query is going to retrieve.
evgeny gridasov wrote:
Hi Everybody.
I am going to replace some 'select count(*) from ... where ...' queries
which run on large tables (10M+ rows) with something like
'explain select * from ... where ' and parse planner output after that
to find out its forecast about number of rows the
unsubscribe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Nelba Sánchez R.
Servicios Tecnológicos de Gestión (STG)
Background: We are running a
web application on apache with database server as PostgreSQL. The application
is a expense claim application with workflow. The software versions are
specified below:
Red Hat Linux release 7.3
Apache 1.3.20
PostgreSQL 7.1.3
Problem: When the
application
Anu Kucharlapati [EMAIL PROTECTED] writes:
Red Hat Linux release 7.3
Apache 1.3.20
PostgreSQL 7.1.3
I'm not sure about Apache, but both the RHL and Postgres versions
you are using are stone age --- *please* update. Red Hat stopped
supporting that release years ago, and the PG community isn't
14 matches
Mail list logo
