From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Multiple DB join |
Date: | 2006-08-15 14:45:39 |
Message-ID: | 20060815144539.GE21939@phlogiston.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Tue, Aug 15, 2006 at 10:35:36AM -0400, Sumeet wrote:
>
> The reason for splitting up the dbs into differnet instances is that in case
> one of the postgres instances on the server
> goes down for some reason, it doesnt effect the other instances which are
> running on the same server. Even I dont know
> the reason for this kind of approach. But i've to deal with it.
I certainly sympathise with the situation where managers decide to
solve problems that never happen. Given that these are on the same
server, it is _way_ more likely that you'll introduce a problem due
to running several instances of the back end than that one instance
of Postgres will magically die (especially in such a way that other
instances will continue to work). But if Some Important Person
decreed it, you have my sympathy.
> I previously thought of doing the full text search indexing thing...but i
> had a intution that the full text search thing is for fields which have very
> large strings.......but in my case the strings are not above 200 chars in
No, it's for data where you're going to be searching in random pieces
of the text. I think you should look at tsearch2, probably.
If you had any way to enforce bounded searches, it'd be a different
matter: strings with initial matches but an unbound end are fast.
(You can do it the other way, too, by some tricks with reversing the
strings.)
A
--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Bono | 2006-08-15 19:18:13 | Re: The Right Way to manage schemas in SCM systems |
Previous Message | Sumeet | 2006-08-15 14:35:36 | Re: Multiple DB join |