Vivek Khera <[EMAIL PROTECTED]> writes:
> On Dec 13, 2005, at 2:49 AM, [EMAIL PROTECTED] wrote:
>
> > What is the performance difference between U320 15kRPM and U320 10kRPM ?
> > Does your RAID crontoller has some memory (e.g. 128 MB or 256 MB )
> > and something like memory backup write cache
On Dec 13, 2005, at 3:50 AM, Benjamin Arai wrote:
What kind of performance boost do you get from using raid 10? I am
trying
to do a little cost analysis.
For small amounts of data you probably wont notice anything. Once
you get into the 10's of GB you'll notice improvement when you have
On Dec 13, 2005, at 2:49 AM, [EMAIL PROTECTED] wrote:
What is the performance difference between U320 15kRPM and U320
10kRPM ?
Does your RAID crontoller has some memory (e.g. 128 MB or 256 MB )
and something like memory backup write cache (like HP DL 380 server) ?
Do you use Intel or Opteron
> [EMAIL PROTECTED]
> Sent: Monday, December 12, 2005 11:50 PM
> To: [EMAIL PROTECTED]
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Performance large tables.
>
> Hello,
>
> may I ask you some questions.
>
> What is the performance difference betwe
,
-Franz
-Ursprüngliche Nachricht-
Von: Vivek Khera [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 12. Dezember 2005 23:15
An: PG-General General
Betreff: Re: [GENERAL] Performance large tables.
On Dec 10, 2005, at 6:37 PM, Benjamin Arai wrote:
> For the most part the updates are simple
On Dec 10, 2005, at 6:37 PM, Benjamin Arai wrote:
For the most part the updates are simple one liners. I currently
commit in large batch to increase performance but it still takes a
while as stated above. From evaluating the computers performance
during an update, the system is thrashin
Please start new threads to ask unrelated questions, rather than replying
to an existing thread. This makes the archives less useful, and may keep
people from seeing your question.
On Sat, Dec 10, 2005 at 15:37:01 -0800,
Benjamin Arai <[EMAIL PROTECTED]> wrote:
> To be more specific, there are
Benjamin Arai wrote:
For the most part the updates are simple one liners. I currently commit
in large batch to increase performance but it still takes a while as
stated above. From evaluating the computers performance during an
update, the system is thrashing both memory and disk. I am curr
Benjamin Arai
wrote on Saturday, December 10, 2005 3:37 PM
> ... On the other hand there is a weekly update (This is the
> problem) that updates all of the modified records for a bunch of
> finacial data such as closes and etc. For the most part they are
> records of the type name,date,value.
On Saturday 10 December 2005 19:28, Jaime Casanova wrote:
> On 12/10/05, Benjamin Arai <[EMAIL PROTECTED]> wrote:
> > To be more specific, there are two types of commands that are run on
> > the system. There are application commands that do all different types
> > of joins and etc but for the mo
On 12/10/05, Benjamin Arai <[EMAIL PROTECTED]> wrote:
> To be more specific, there are two types of commands that are run on
> the system. There are application commands that do all different types
> of joins and etc but for the most part are fast enough to meet user
> expectations. On the other
To be more specific, there are two types of commands that are run on
the system. There are application commands that do all different types
of joins and etc but for the most part are fast enough to meet user
expectations. On the other hand there is a weekly update (This is the
problem) that
On Sat, Dec 10, 2005 at 03:22:47PM -0800, Benjamin Arai wrote:
> My issue actually stems from the fact that I cannot do large weekly
> updates on fast enough to meet a weekend window for the following work
> week. I am currently using a machine with a raid 1, 4GB RAM, and dual
> opteron. I cou
My issue actually stems from the fact that I cannot do large weekly
updates on fast enough to meet a weekend window for the following work
week. I am currently using a machine with a raid 1, 4GB RAM, and dual
opteron. I could go 0+1 but peroformance increase is only about 20%
from the benchma
14 matches
Mail list logo
