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 21B3B52918 for ; Thu, 2 Jun 2005 12:48:21 -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 38461-06 for ; Thu, 2 Jun 2005 15:48:17 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by svr1.postgresql.org (Postfix) with ESMTP id 1AFAE52931 for ; Thu, 2 Jun 2005 12:48:16 -0300 (ADT) Received: by rproxy.gmail.com with SMTP id i8so259715rne for ; Thu, 02 Jun 2005 08:48:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WvEd0mMZBfwLyUrxn0KjhCrDGipHdDnnxJ9qKfugjl8PihjcySzzWeEF3cdyuZ16tYkwnPYmG4TuUm/PMa6Tg1eZV6Gn3WbBF4StU5VBv25/2PN93aelgJGIYcgM2KSi90x/WXa2YiBtmVZWs5nvdvHC836rB9VECPonWr99TlY= Received: by 10.38.92.63 with SMTP id p63mr416409rnb; Thu, 02 Jun 2005 08:48:21 -0700 (PDT) Received: by 10.38.97.37 with HTTP; Thu, 2 Jun 2005 08:48:21 -0700 (PDT) Message-ID: Date: Thu, 2 Jun 2005 10:48:21 -0500 From: Jaime Casanova Reply-To: Jaime Casanova To: Richard Huxton Subject: Re: [SQL] index row size 2728 exceeds btree maximum, 27 Cc: =?ISO-8859-1?Q?K=D6PFERL_Robert?= , "dpandey@secf.com" , pgsql-general@postgresql.org, PostgreSQL In-Reply-To: <429EFE55.3050601@archonet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <429EFE55.3050601@archonet.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.341 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200506/101 X-Sequence-Number: 78809 On 6/2/05, Richard Huxton wrote: > K=D6PFERL Robert wrote: > > To me it seems that the definer of this table missed the concept index = ... > > or the concept database > > One usually looks up data using a key, but if the whole row is the key,= what > > data shall be looked up. >=20 > > So short story long: Remove data from your index. The data column seem= s > > like the data to be looked up using the key > > (scan_id, host_ip, port_num, plugin_id, severity) or even less. > > Postgres is able to take several indices over distinct columns into acc= ount. > > Thus reducing the possible candidates to a hand full. > > So several indices are also an option >=20 > 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. >=20 If this a log he will need a timestamp field to be usefull, making that field part of the primary key and letting the data out of the primary has more sense to me. --=20 regards, Jaime Casanova (DBA: DataBase Aniquilator ;)