X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id F14DB11F6C38 for ; Wed, 12 Apr 2006 17:44:31 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 required=5 tests=[AWL=0.451] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id OrIsTx5osarI for ; Wed, 12 Apr 2006 17:44:23 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 8271111F6B55 for ; Wed, 12 Apr 2006 17:44:22 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 991E956427; Wed, 12 Apr 2006 15:44:22 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 12 Apr 2006 15:44:22 -0500 Date: Wed, 12 Apr 2006 15:44:22 -0500 From: "Jim C. Nasby" To: Markus Schaber Cc: Oscar Picasso , pgsql-performance@postgresql.org Subject: Re: Better index stategy for many fields with few values Message-ID: <20060412204421.GK49405@pervasive.com> References: <20060410165857.91471.qmail@web54705.mail.yahoo.com> <443CF9B4.2080009@logix-tt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <443CF9B4.2080009@logix-tt.com> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060412:schabi@logix-tt.com::a0oOP3skof/X3zxs:000000000000000000 0000000000000000000000001Ggt X-Hashcash: 1:20:060412:oscgoogle@yahoo.com::8IAmngb568b7I2c5:000000000000000000 0000000000000000000000001mJA X-Hashcash: 1:20:060412:pgsql-performance@postgresql.org::vdTeKlF9Jfsy8BCw:00000 0000000000000000000000000vrZ X-Archive-Number: 200604/272 X-Sequence-Number: 18356 On Wed, Apr 12, 2006 at 02:59:32PM +0200, Markus Schaber wrote: > > I was thinking about using a multicolumns index, but I have read that > > we should limit multicolumns indice to at most 2 or 3 columns. > > Yes, that's true, the index overhead gets too high. > > > I was also thinking about about using a functional index. > > If there's a logical relation between those values that they can easily > combined, that may be a good alternative. How would that be any better than just doing a multi-column index? > I just had another weird idea: > > As your paramXX values can have only 10 parameters, it also might be > feasible to use a bunch of 10 conditional indices, like: > > CREATE INDEX foo1 ON table (param1, param2 WHERE param0='1st value'; > CREATE INDEX foo2 ON table (param1, param2 WHERE param0='2nd value'; > CREATE INDEX foo3 ON table (param1, param2 WHERE param0='3rd value'; > [...] Not all that weird; it's known as index partitioning. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461