Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 21A0598F705 for ; Tue, 5 Jun 2012 11:57:32 -0300 (ADT) Received: from smtp2.peak6.com ([38.98.137.9]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SbvCL-00012W-3U for pgsql-performance@postgresql.org; Tue, 05 Jun 2012 14:57:31 +0000 X-AuditID: 0a02cb1e-b7fa76d000000a63-28-4fce1e37828b Message-ID: <4FCE1E4A.60704@optionshouse.com> Date: Tue, 5 Jun 2012 09:57:14 -0500 From: Shaun Thomas Reply-To: Organization: Peak6 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" Subject: Re: Sequencial scan in a JOIN References: , <4FCE0681.5040306@optionshouse.com> , <4FCE1160.4070003@optionshouse.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.201.64] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsXClcIrpmshd87f4O4LNovrM88xOzB6XNg3 jT2AMaqB0SYxLy+/JLEkVSEltTjZVsm/oCQzP6/YI7+0OFXBJbM4OScxMze1SEkhM8VWyVxJ oSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZxSOD hE6WjC3fgwqWc1VcvVDYwDiVo4uRk0NCwETi+sXDTBC2mMSFe+vZuhg5OHgFdCXOrCgCCbMI qEj0LelgA7HZgMKT+leA2UIg8bM3wFr5BYQl9n1oYgaxRQVCJM49+Q5WwysgKHFy5hMWEFtE wFNi9v5tYLawgIFET9deoHouoDl3GSUmLdnFCJLgFLCS2HfjLpjNLGArcWHOdRYIW15i+9s5 zBCLVSVWNE9kg7hZQeL/lXdMExgFZyHZNwtJ+ywk7QsYmVcxiheXJSZnZJoVFOeWFBjqFaQm Zpvp5aWWbGIERSLTabkdjCsuKB5iFOBgVOLhLTh7xl+INbGsuDL3EKMEB7OSCG9W+Fl/Id6U xMqq1KL8+KLSnNTiQ4ymwICayCwlmpwPTBJ5JfGGxoaWppYmZpbmxsYGSuK839cCzRFIByaA 7NTUgtQimD4mDk6pBkZzl9Dea8IH3M3+iSk0+O4/t2yTm+WXmo470nHpYvsDF88vSFhmdvi6 uX3buo7JC/ylHWas2nHiTvNXbRG159vK7PcHe3Sz7vuU//2Ljt6zp8cP2y5x3vWVXzXo4MJ5 2d+PXN379OEF49W5B9ZMi05QNU3etKIsT+FUqaPlp+km6nvX3LY+Z3dSiaU4I9FQi7moOBEA TX6OKdoCAAA= X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/23 X-Sequence-Number: 47049 On 06/05/2012 09:41 AM, Andrew Jaimes wrote: > The second query ran better than the first one: That's what I figured. Ok, so looking back to your original message again: CREATE INDEX i08_a_activity ON a_activity USING btree (activequeueid , vstatus , ventrydate ); Based on the query here, it doesn't appear that vstatus or ventrydate are doing you any good in that index. Nor would your query even really make use of them anyway, considering their catch-all equalities. If you can make a clone of a_activity, could you try this index instead with your original query: CREATE INDEX idx_a_activity_queue ON a_activity_clone (activequeueid); Then compare to this: CREATE INDEX idx_a_activity_queue_sbuid ON a_activity_clone (activequeueid, sbuid); And the results of this query would also be handy: SELECT attname, n_distinct FROM pg_stats WHERE tablename='a_activity'; Generally you want to order your composite indexes in order of uniqueness, if you even want to make a composite index in the first place. I noticed in both cases, it's basically ignoring sbuid aside from the implied hash to exclude non-matches. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-444-8534 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email