Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X0GFz-0003gV-Ng for pgsql-performance@arkaria.postgresql.org; Thu, 26 Jun 2014 20:26:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X0GFz-0001d6-6p for pgsql-performance@arkaria.postgresql.org; Thu, 26 Jun 2014 20:26:55 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X0GFx-0001cz-VS for pgsql-performance@postgresql.org; Thu, 26 Jun 2014 20:26:54 +0000 Received: from smtp2.peak6.com ([38.98.137.9]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X0GFu-0005kw-N9 for pgsql-performance@postgresql.org; Thu, 26 Jun 2014 20:26:52 +0000 X-AuditID: 0a02cb20-f798c6d000007a0a-99-53ac8208cb75 Received: from sswchi5pcas1.peak6.net (Unknown_Domain [10.100.13.22]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by smtp2.peak6.com (Symantec Messaging Gateway) with SMTP id 2B.41.31242.8028CA35; Thu, 26 Jun 2014 15:26:48 -0500 (CDT) Received: from [10.10.220.56] (10.10.220.56) by sswchi5pcas1.peak6.net (10.100.13.25) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Jun 2014 15:26:47 -0500 Message-ID: <53AC8203.5030809@optionshouse.com> Date: Thu, 26 Jun 2014 15:26:43 -0500 From: Shaun Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeff Janes , Aaron Weber CC: "pgsql-performance@postgresql.org" Subject: Re: how to improve perf of 131MM row table? References: <53AB2CB1.8080201@comcast.net> <53AB35CC.10202@optionshouse.com> <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.220.56] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42LhSuEV0+VoWhNs8OS/qcXd9ffYLaZ9P8Rk cX3mOWYHZo/Jj+cweuycdZfd48K+aewBzFENjDaJeXn5JYklqQopqcXJtkr+BSWZ+XnFHvml xakKLpnFyTmJmbmpRUoKmSm2SsZKCgU5icmpual5JbZKiQUFqXkpSnZcChjABqgsM08hNS85 PyUzL91WyTPYX9fCwtRS11DJLh4ZJHSyZOzbYVwwh7Ni9bHnzA2MK9m7GDk5JARMJA5u7WKG sMUkLtxbz9bFyMUhJDCXSWLfofssEM5KRokHXT8YQap4BfQlpn77ywRiswioSkxbeRssziag KzGpfwUbiC0qECbxeM45qHpBiZMzn7CA2CIC7hJfrm0Eq2EW8JToOLUKrEZYwE5izs2DUMtO MUrM/XoHbAGnQKDEk/dr2CEaLCQWvzkIZctLbH87B+xsIaAjVjRPBBrKAfSCAtALqRMYhWYh WT0LSfcsJN0LGJlXMYoXlyUmZ2SaFRTnlhQY6RWkJmab6eWllmxiBMUz02mFHYybe6wOMQpw MCrx8E4IXBMsxJpYVlyZe4hRgoNZSYRXpwEoxJuSWFmVWpQfX1Sak1p8iNEHGDYTmaVEk/OB qSavJN7Q2NTA1NLU0NTc1NAIh7CSOO+RlrhgIYF0YDLJTk0tSC2CGcfEwSnVwDhx4+cF546U rNeIqjJ+VFhtyjLr9tl9TY4RAbeWahmfND2/58nBdEe7PRaPFNYLPA3ec/PQs0Nvz77cGWm9 R6gpOvz0qv6cS/4Jtoy79JWnqG95yV/lE3rwdESIiMrKgs6nH1MsD3G84bw5d8aK6in3TqgE pIZs38fYkpftdqF8p1J1yjrxE4uVWIozEg21mIuKEwFvxkf5FAMAAA== X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 06/26/2014 03:14 PM, Jeff Janes wrote: > If that is 50 PKs from the master table, it would be about 1000 on the > detail table. You're right. But here's the funny part: we solved this after we noticed his where clause was directed at the *detail* table instead of the master table. This was compounded by the fact the planner incorrectly estimated the row match count on the detail table due to the well-known correlation deficiencies especially present in older versions. The row count went from 1000 to 50,000. Then it joined against the master table. Since 50,000 index page fetches followed by 50,000 data page fetches would be pretty damn slow, the planner went for a sequence scan on the master table instead. Clearly the old 9.0 planner does not consider transitive IN equality. I'm curious to see if Aaron can test his structure on 9.3 with the original data and WHERE clause and see if the planner still goes for the terrible plan. If it does, that would seem like an obvious planner tweak to me. -- Shaun Thomas OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance