X-Original-To: pgsql-sql@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 9885B475EFD for ; Mon, 3 Mar 2003 17:47:50 -0500 (EST) Received: from postgresql.org ([64.49.215.8]) by localhost (postgresql.org [64.49.215.8:10024]) (amavisd-new) with SMTP id 22806-02 for ; Mon, 3 Mar 2003 17:47:47 -0500 (EST) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by postgresql.org (Postfix) with ESMTP id 7229447635A for ; Mon, 3 Mar 2003 17:21:17 -0500 (EST) Received: from stark.dyndns.tv (H162.C233.tor.velocet.net [216.138.233.162]) by sabre.velocet.net (Postfix) with ESMTP id 7B6BF138299; Mon, 3 Mar 2003 17:21:13 -0500 (EST) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 18pyJ7-0005FD-00; Mon, 03 Mar 2003 17:21:13 -0500 To: Michael Nachbaur Cc: pgsql-sql@postgresql.org Subject: Re: Forcing query to use an index References: In-Reply-To: From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 03 Mar 2003 17:21:12 -0500 Message-ID: <87r89ohz1j.fsf@stark.dyndns.tv> Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new X-Archive-Number: 200303/95 X-Sequence-Number: 12135 Michael Nachbaur writes: >-> Merge Join (cost=6106.42..6335.30 rows=2679 width=265) (actual time=859.77..948.06 rows=1 loops=1) > -> Merge Join (cost=6101.24..6319.77 rows=2679 width=247) (actual time=554.11..674.17 rows=2679 loops=1) > -> Index Scan using customer_id_key on customer c (cost=0.00..129.63 rows=2679 width=156) (actual time=0.40..43.43 rows=2679 loops=1) > -> Sort (cost=6101.24..6101.24 rows=8117 width=91) (actual time=553.64..559.58 rows=8117 loops=1) > -> Seq Scan on customer_month_summary cms (cost=0.00..5574.17 rows=8117 width=91) (actual time=258.03..477.11 rows=8117 loops=1) You should send the query as well, and \d customer_month_summary so we can see how you defined your indexes. There doesn't seem to be a filter on the scan so it looks like postgres thinks you're actually reading in the entire table, which is normally faster with a sequential scan than an index scan. In fact I'm surprised it's doing an index scan on the other table and not a sequential scan. Some things to try: set enable_seqscan = off Then try your query again, see if postgres is right and it really is faster to do the sequential scan. set random_page_cost = 2 Or even lower values. I've also had some success with raising cpu_tuple_cost, though I'm unclear on whether that's actually a good approach or not. Also, don't forget to do a vacuum full on these tables before doing testing for optimizations at this level. You can get some confusing results if your tables have lots of empty holes in them. -- greg