X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 7C37C52906 for ; Thu, 2 Jun 2005 13:36:37 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 52665-06 for ; Thu, 2 Jun 2005 16:36:35 +0000 (GMT) Received: from wolff.to (wolff.to [66.93.197.194]) by svr1.postgresql.org (Postfix) with SMTP id CBD55528CB for ; Thu, 2 Jun 2005 13:36:33 -0300 (ADT) Received: (qmail 23661 invoked by uid 500); 2 Jun 2005 16:35:42 -0000 Date: Thu, 2 Jun 2005 11:35:42 -0500 From: Bruno Wolff III To: Richard Huxton Cc: =?iso-8859-1?Q?K=D6PFERL?= Robert , "'dpandey@secf.com'" , pgsql-general@postgresql.org, 'PostgreSQL' Subject: Re: [SQL] index row size 2728 exceeds btree maximum, 27 Message-ID: <20050602163542.GA23150@wolff.to> Mail-Followup-To: Bruno Wolff III , Richard Huxton , =?iso-8859-1?Q?K=D6PFERL?= Robert , "'dpandey@secf.com'" , pgsql-general@postgresql.org, 'PostgreSQL' References: <429EFE55.3050601@archonet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429EFE55.3050601@archonet.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.008 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/106 X-Sequence-Number: 78814 On Thu, Jun 02, 2005 at 13:40:53 +0100, Richard Huxton wrote: > > Actually, Dinesh didn't mention he was using this for the speed of > lookup. He'd defined the columns as being the PRIMARY KEY, presumably > because he feels they are/should be unique. Given that they are rows > from a logfile, I'm not convinced this is the case. Even for case you could still use hashes. The odds of a false collision using SHA-1 are so small that some sort of disaster is more likely. Another possibility is if there are a fixed number of possible messages, is that they could be entered in their own table with a serail PK and the other table could reference the PK.