Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 902DA632ADF for ; Wed, 25 Mar 2009 23:15:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 60670-01 for ; Wed, 25 Mar 2009 23:15:11 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id D9F356358BD for ; Wed, 25 Mar 2009 23:15:19 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n2Q2FEDv011651; Wed, 25 Mar 2009 22:15:14 -0400 (EDT) To: Bryan Murphy cc: Josh Berkus , pgsql-performance@postgresql.org Subject: Re: Help Me Understand Why I'm Getting a Bad Query Plan In-reply-to: <7fd310d10903251514x1dd522f3o8d13a9218a6eda6c@mail.gmail.com> References: <7fd310d10903231203r1bd37b8cn8baeadae83253f44@mail.gmail.com> <7fd310d10903241521v1cbf5d7aueca653e03ed98649@mail.gmail.com> <7fd310d10903242047t1a7b7daw1d61c3de7f20b7c6@mail.gmail.com> <49CAA85C.8080402@agliodbs.com> <7fd310d10903251514x1dd522f3o8d13a9218a6eda6c@mail.gmail.com> Comments: In-reply-to Bryan Murphy message dated "Wed, 25 Mar 2009 17:14:45 -0500" Date: Wed, 25 Mar 2009 22:15:14 -0400 Message-ID: <11650.1238033714@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.013 tagged_above=0 required=5 tests=AWL=0.013 X-Spam-Level: X-Archive-Number: 200903/372 X-Sequence-Number: 33294 Bryan Murphy writes: > I tried that already, but I decided to try again in case I messed up > something last time. Here's what I ran. As you can see, it still > chooses to do a sequential scan. Am I changing the stats for those > columns correctly? I think what you should be doing is messing with the cost parameters ... and not in the direction you tried before. I gather from effective_cache_size = 12GB that you have plenty of RAM on this machine. If the tables involved are less than 1GB then it's likely that you are operating in a fully cached condition, and the default cost parameters are not set up for that. You want to be charging a lot less for page accesses relative to CPU effort. Try reducing both seq_page_cost and random_page_cost to 0.5 or even 0.1. You'll need to watch your other queries to make sure nothing gets radically worse though ... regards, tom lane