DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=akHVlRYJ02H0PDPuDv/e84h115C5Zk6FwUE3USQDOkBsM4YcNMf88fIhmrd2Zvhoz9maRWiLsqbwx2/CMcITT2t7sp8wDx/A61nCNtwTbf+Wxc/gTNgnxZDMSNwRYZvk1Kn/qR43yl03/X1YCwt6y9Rw4PjEnCG8IPiEj0Io8L0=
Message-ID: <33c6269f050819054038af9886@mail.gmail.com>
Date: Fri, 19 Aug 2005 08:40:39 -0400
From: Alex Turner <armtuk@gmail.com>
To: Mark Cotner <mcotner@yahoo.com>
Subject: Re: sustained update load of 1-2k/sec
Cc: pgsql-performance@postgresql.org
In-Reply-To: <20050819082404.53751.qmail@web32915.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20050819082404.53751.qmail@web32915.mail.mud.yahoo.com>

I have managed tx speeds that high from postgresql going even as high
as 2500/sec for small tables, but it does require a good RAID
controler card (yes I'm even running with fsync on).  I'm using 3ware
9500S-8MI with Raptor drives in multiple RAID 10s.  The box wasn't too
$$$ at just around $7k.  I have two independant controlers on two
independant PCI buses to give max throughput. on with a 6 drive RAID
10 and the other with two 4 drive RAID 10s.

Alex Turner
NetEconomist

On 8/19/05, Mark Cotner <mcotner@yahoo.com> wrote:
> Hi all,
> I bet you get tired of the same ole questions over and
> over.
>=20
> I'm currently working on an application that will poll
> thousands of cable modems per minute and I would like
> to use PostgreSQL to maintain state between polls of
> each device.  This requires a very heavy amount of
> updates in place on a reasonably large table(100k-500k
> rows, ~7 columns mostly integers/bigint).  Each row
> will be refreshed every 15 minutes, or at least that's
> how fast I can poll via SNMP.  I hope I can tune the
> DB to keep up.
>=20
> The app is threaded and will likely have well over 100
> concurrent db connections.  Temp tables for storage
> aren't a preferred option since this is designed to be
> a shared nothing approach and I will likely have
> several polling processes.
>=20
> Here are some of my assumptions so far . . .
>=20
> HUGE WAL
> Vacuum hourly if not more often
>=20
> I'm getting 1700tx/sec from MySQL and I would REALLY
> prefer to use PG.  I don't need to match the number,
> just get close.
>=20
> Is there a global temp table option?  In memory tables
> would be very beneficial in this case.  I could just
> flush it to disk occasionally with an insert into blah
> select from memory table.
>=20
> Any help or creative alternatives would be greatly
> appreciated.  :)
>=20
> 'njoy,
> Mark
>=20
>=20
> --
> Writing software requires an intelligent person,
> creating functional art requires an artist.
> -- Unknown
>=20
>=20
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>=20
>                http://www.postgresql.org/docs/faq
>