Re: Multiple DB join - Mailing list pgsql-sql

From Andrew Sullivan
Subject Re: Multiple DB join
Date
Msg-id 20060815144539.GE21939@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Multiple DB join  (Sumeet <asumeet@gmail.com>)
Responses Re: Multiple DB join  (Sumeet <asumeet@gmail.com>)
List 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@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.    --Philip Greenspun


pgsql-sql by date:

Previous
From: Sumeet
Date:
Subject: Re: Multiple DB join
Next
From: Kis János Tamás
Date:
Subject: Re: Undo an update