Re: Hardware recommendations to scale to silly load - Mailing list pgsql-performance

From Ron Johnson
Subject Re: Hardware recommendations to scale to silly load
Date
Msg-id 1062220877.669.406.camel@haggis
Whole thread Raw
In response to Re: Hardware recommendations to scale to silly load  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Selecting random rows efficiently
Re: Hardware recommendations to scale to silly load
Re: Hardware recommendations to scale to silly load
List pgsql-performance
On Fri, 2003-08-29 at 21:44, Bruce Momjian wrote:
> matt wrote:
> > > Are you *sure* about that????  3K updates/inserts per second xlates
> > > to 10,800,000 per hour.  That, my friend, is a WHOLE HECK OF A LOT!
> >
> > Yup, I know!
>
> Just a data point, but on my Dual Xeon 2.4Gig machine with a 10k SCSI
> drive I can do 4k inserts/second if I turn fsync off.  If you have a
> battery-backed controller, you should be able to do the same.  (You will
> not need to turn fsync off --- fsync will just be fast because of the
> disk drive RAM).
>
> Am I missing something?

Is that
    FOR I BETWEEN 1 AND 4000
        BEGIN
           INSERT
        COMMIT
or
    BEGIN
        INSERT
        <snip 3998 inserts>
        INSERT
    COMMIT;
or
    COPY

I get the impression that Matt will need to do 25,000 of these per
hour:
    SELECT <blah>
    IF <some circumstance that happens about 1/8th of the time>
        BEGIN
            INSERT
               or
            UPDATE
        COMMIT;

He says his current h/w peaks at 1/10th that rate.

My question is: is that current peak rate ("300 inserts/updates
*or* 2500 selects") based upon 1 connection, or many connections?
With 4 CPUs, and a 4 disk RAID10, I wouldn't be surprised if 4 con-
current connections gives the optimum speed.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA

Great Inventors of our time:
Al Gore -> Internet
Sun Microsystems -> Clusters


pgsql-performance by date:

Previous
From: Ken Geis
Date:
Subject: Re: bad estimates
Next
From: Richard Jones
Date:
Subject: Selecting random rows efficiently