Skip site navigation (1) Skip section navigation (2)

Re: Hardware recommendations to scale to silly load

From: "Matt Clark" <matt(at)ymogen(dot)net>
To: "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>,"PgSQL Performance ML" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hardware recommendations to scale to silly load
Date: 2003-08-30 15:36:20
Message-ID: OAEAKHEHCMLBLIDGAFELGEHIDHAA.matt@ymogen.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
>     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.

Well it's more like each user interaction looks like:

	SELECT
	SELECT
	SELECT
	SELECT
	SELECT
	SELECT
	INSERT
	SELECT
	SELECT
	SELECT
	SELECT
	INSERT
	SELECT
	SELECT
	SELECT
	UPDATE
	SELECT
	SELECT
	UPDATE
	SELECT

And concurrency is very high, because it's a web app, and each httpd has one connection to PG, and there can be hundreds of active
httpd processes.  Some kind of connection pooling scheme might be in order when there are that many active clients.  Any views?



In response to

Responses

pgsql-performance by date

Next:From: Rob NaglerDate: 2003-08-30 15:47:02
Subject: Re: How to force Nested Loop plan?
Previous:From: Tom LaneDate: 2003-08-30 15:14:04
Subject: Re: Selecting random rows efficiently

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2003-08-30 15:37:01
Subject: Re: [HACKERS] What goes into the security doc?
Previous:From: Jonathan GardnerDate: 2003-08-30 15:32:36
Subject: ALTER TABLE ... TO ... to change related names

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group