Message-ID: <4DBDED43.4050303@2ndQuadrant.com>
Date: Sun, 01 May 2011 19:31:15 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: stored proc and inserting hundreds of thousands of
 rows
References: <D5DE36B9-17CF-4A55-9119-CDC0BDC4E48D@gmail.com>
	<4DBC004C020000250003D099@gw.wicourts.gov>	<4881277622113933088@unknownmsgid>
	<4DBC0D7C020000250003D09E@gw.wicourts.gov>
	<DEBFB8EB-6F50-4462-8827-434E0CE308C7@gmail.com>
	<BANLkTikrXYJpJGzsUtpFgS8YiAO+d7y6PA@mail.gmail.com>
	<76A45DA2-2AC3-4F58-933B-D4DCD61B8DCE@gmail.com>
	<BANLkTik5WUmBDEU1vjW13ieVK9TqTUn9cA@mail.gmail.com>
	<BANLkTi=ML2MbgEP-pRdAsHaCFp9s3w+DWA@mail.gmail.com>
In-Reply-To: <BANLkTi=ML2MbgEP-pRdAsHaCFp9s3w+DWA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 04/30/2011 09:00 PM, Samuel Gendler wrote:
> Some kind of in-memory cache of doc/ad mappings which the ad server 
> interacts with will serve you in good stead and will be much easier to 
> scale horizontally than most relational db architectures lend 
> themselves to...Even something as simple as a process that pushes the 
> most recent doc/ad mappings into a memcache instance could be 
> sufficient - and you can scale your memcache across as many hosts as 
> is necessary to deliver the lookup latencies that you require no 
> matter how large the dataset. 

Many of the things I see people switching over to NoSQL key/value store 
solutions would be served equally well on the performance side by a 
memcache layer between the application and the database.  If you can map 
the problem into key/value pairs for NoSQL, you can almost certainly do 
that using a layer above PostgreSQL instead.

The main downside of that, what people seem to object to, is that it 
makes for two pieces of software that need to be maintained; the NoSQL 
solutions can do it with just one.  If you have more complicated queries 
to run, too, the benefit to using a more complicated database should 
outweigh that extra complexity though.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books