X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 4FDE79FB2AB for ; Tue, 15 Aug 2006 11:45:56 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 91739-02 for ; Tue, 15 Aug 2006 14:45:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from main2.mycybernet.net (main2.mycybernet.net [209.222.63.140]) by postgresql.org (Postfix) with ESMTP id 87E769FB274 for ; Tue, 15 Aug 2006 11:45:46 -0300 (ADT) Received: from 227-54-222-209.mycybernet.net ([209.222.54.227] helo=phlogiston.dydns.org) by main2.mycybernet.net with esmtp (Exim 4.62) (envelope-from ) id 1GD0N2-00082k-T5 for pgsql-sql@postgresql.org; Tue, 15 Aug 2006 10:58:21 -0400 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 1BB844172; Tue, 15 Aug 2006 10:45:39 -0400 (EDT) Date: Tue, 15 Aug 2006 10:45:39 -0400 From: Andrew Sullivan To: pgsql-sql@postgresql.org Subject: Re: Multiple DB join Message-ID: <20060815144539.GE21939@phlogiston.dyndns.org> References: <44E0EA72.2090505@indiana.edu> <20060815103624.GA21634@phlogiston.dyndns.org> <44E1D61D.4020400@indiana.edu> <20060815141712.GB21939@phlogiston.dyndns.org> <7539aebb0608150735l34e59630m25487549c8e6de2d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7539aebb0608150735l34e59630m25487549c8e6de2d@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.135 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200608/113 X-Sequence-Number: 26071 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