Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 1D9899FB899 for ; Fri, 18 May 2007 17:06:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 11279-05 for ; Fri, 18 May 2007 17:06:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id C07C39FB87C for ; Fri, 18 May 2007 17:06:12 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l4IK69HQ001826; Fri, 18 May 2007 16:06:09 -0400 (EDT) To: Scott Marlowe cc: "Tyrrill, Ed" , pgsql-performance@postgresql.org Subject: Re: Slow queries on big table In-reply-to: <464E0036.3030804@g2switchworks.com> References: <464E0036.3030804@g2switchworks.com> Comments: In-reply-to Scott Marlowe message dated "Fri, 18 May 2007 14:36:22 -0500" Date: Fri, 18 May 2007 16:06:09 -0400 Message-ID: <1825.1179518769@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/345 X-Sequence-Number: 24735 Scott Marlowe writes: > Secondly, it might be more efficient for the planner to choose the > backup_location_rid index than the combination primary key index. Oh, I'm an idiot; I didn't notice the way the index was set up. Yeah, that index pretty well sucks for a query on backup_id --- it has to scan the entire index, since there's no constraint on the leading column. So that's where the time is going. This combination of indexes: > Indexes: > "backup_location_pkey" PRIMARY KEY, btree (record_id, backup_id) > "backup_location_rid" btree (record_id) is really just silly. You should have the pkey and then an index on backup_id alone. See the discussion of multiple indexes in the fine manual: http://www.postgresql.org/docs/8.2/static/indexes-multicolumn.html http://www.postgresql.org/docs/8.2/static/indexes-bitmap-scans.html regards, tom lane