Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id E5E569FB2E0 for ; Wed, 18 Oct 2006 09:50:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 90155-06 for ; Wed, 18 Oct 2006 09:50:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.envysolutions.com (mark.mielke.cc [206.248.142.186]) by postgresql.org (Postfix) with ESMTP id 6817B9FB289 for ; Wed, 18 Oct 2006 09:50:11 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envysolutions.com (Postfix) with ESMTP id C551B5403B; Wed, 18 Oct 2006 08:50:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.envysolutions.com Received: from mail.envysolutions.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61OJ7-M8+e6M; Wed, 18 Oct 2006 08:50:09 -0400 (EDT) Received: by mail.envysolutions.com (Postfix, from userid 500) id 9C3D25403C; Wed, 18 Oct 2006 08:50:09 -0400 (EDT) Date: Wed, 18 Oct 2006 08:50:09 -0400 From: mark@mark.mielke.cc To: Mario Weilguni Cc: Alexander Staubo , pgsql-performance@postgresql.org, Ruben Rubio Subject: Re: Optimization of this SQL sentence Message-ID: <20061018125009.GA10759@mark.mielke.cc> References: <45349CDF.3090002@rentalia.com> <200610171729.19596.mweilguni@sime.com> <200610181131.44840.mweilguni@sime.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610181131.44840.mweilguni@sime.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.14 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, NO_REAL_NAME, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * X-Archive-Number: 200610/350 X-Sequence-Number: 21479 On Wed, Oct 18, 2006 at 11:31:44AM +0200, Mario Weilguni wrote: > It's not a bad idea. Usually I use postal codes with 25 chars, and never had > any problem. With text, the limit would be ~1 GB. No matter how much testing > in the application happens, the varchar(25) as last resort is a good idea. > And in most cases, the application itself limits the length, and thus it's > good to reflect this in the database design. > Feel free to use text anywhere for your application, and feel free to use > numeric(1000) instead of numeric(4) if you want to be prepared for really > long numbers, but don't tell other people it's bad database design - it > isn't. It's unnecessary design. Suggestions in this regard lead towards the user seeing a database error, instead of a nice specific message provided by the application. I used to use varchar instead of text, but have since softened, as the number of times it has ever actually saved me is zero, and the number of times it has screwed me up (picking too small of a limit too early) has been a few. It's kind of like pre-optimization before there is a problem. Sometimes it works for you, sometimes it works against. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/