Re: Multiple DB join

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

In response to

Responses

Browse pgsql-sql by date

  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