From: Geoffrey <esoteric@3times25.net>
To: pgsql-performance@postgresql.org
Subject: Re: solutions for new Postgresql application testing
Date: Tue, 01 Nov 2005 18:12:36 -0500
Message-ID: <4367F664.1010709@3times25.net> (raw)
In-Reply-To: <6EE64EF3AB31D5448D0007DD34EEB3417DD759@Herge.rcsinc.local>
References: <6EE64EF3AB31D5448D0007DD34EEB3417DD759@Herge.rcsinc.local>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: esoteric@3times25.net
Subject: Re: solutions for new Postgresql application testing
In-Reply-To: <4367F664.1010709@3times25.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox