X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id B5CD7DB72F
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue,  1 Nov 2005 19:12:27 -0400 (AST)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 25607-04
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue,  1 Nov 2005 23:12:24 +0000 (GMT)
Received: from www.3times25.net (duck.3times25.net [66.23.211.34])
	by svr1.postgresql.org (Postfix) with ESMTP id 3E3C1DB729
	for <pgsql-performance@postgresql.org>;
	Tue,  1 Nov 2005 19:12:26 -0400 (AST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by www.3times25.net (Postfix) with ESMTP id 25C16DB92C
	for <pgsql-performance@postgresql.org>;
	Tue,  1 Nov 2005 18:12:37 -0500 (EST)
Message-ID: <4367F664.1010709@3times25.net>
Date: Tue, 01 Nov 2005 18:12:36 -0500
From: Geoffrey <esoteric@3times25.net>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: solutions for new Postgresql application testing
References: <6EE64EF3AB31D5448D0007DD34EEB3417DD759@Herge.rcsinc.local>
In-Reply-To: <6EE64EF3AB31D5448D0007DD34EEB3417DD759@Herge.rcsinc.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.013 required=5 tests=[AWL=0.013]
X-Spam-Score: 0.013
X-Spam-Level: 
X-Archive-Number: 200511/16
X-Sequence-Number: 15273

Merlin Moncure wrote:
> Geoffrey wrote:
> 
>>We are going live with a application in a few months that is a complete
>>rewrite of an existing application.  We are moving from an existing
>>proprietary database to Postgresql.  We are looking for some
>>insight/suggestions as to how folks test Postgresql in such a situation.
> 
> Shouldn't you run your tests *before* rewriting your application? :).
> You don't have to answer that.

The logic has been proven.  What we want to really test is loading and 
the remote possibility that the compiler built code based on what we 
wrote, rather then what we thought. :)

>>We're also trying to decide whether a single database with multiple
>>schemas or multiple databases are the best solution.  We've done some
>>research on this through the archives, and the answer seems to depend on
>>the database/application design.  Still, we welcome any generic ideas
>>on this issue as well.
> 
> I can help a little bit here.  Yes, this decision will be heavily
> influenced by application design.  Let's assume you have to keep
> multiple identical table sets (suppose you have multiple companies on
> the same server for example).  Here are some general stipulations:

<great feedback snipped>

Thanks muchly for your insights.  Just the kind of info we're looking 
for.  Now if I could only find that mind reading compiler.

We lean towards multiple databases when thinking about the possible need 
to bring down a single database without affecting the others.  We do 
require access to multiple datastores, but that is relatively easily 
done with either schemas or databases with perl and C, which are our 
tools of choice.  These databases are pretty much identical in design, 
simply for different 'parts' of the business.

Any further thoughts are, of course, still welcome.

-- 
Until later, Geoffrey