Re: Multiple DB join
От | Andrew Sullivan |
---|---|
Тема | Re: Multiple DB join |
Дата | |
Msg-id | 20060815144539.GE21939@phlogiston.dyndns.org обсуждение исходный текст |
Ответ на | Re: Multiple DB join (Sumeet <asumeet@gmail.com>) |
Ответы |
Re: Multiple DB join
|
Список | 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 по дате отправления: