Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YFxiH-0008S4-L0 for pgsql-performance@arkaria.postgresql.org; Tue, 27 Jan 2015 04:25:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YFxiH-00033v-0s for pgsql-performance@arkaria.postgresql.org; Tue, 27 Jan 2015 04:25:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YFxiG-00033Z-8k for pgsql-performance@postgresql.org; Tue, 27 Jan 2015 04:25:16 +0000 Received: from mail-wg0-f49.google.com ([74.125.82.49]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YFxi7-0000vW-Ip for pgsql-performance@postgresql.org; Tue, 27 Jan 2015 04:25:15 +0000 Received: by mail-wg0-f49.google.com with SMTP id k14so12568522wgh.8 for ; Mon, 26 Jan 2015 20:25:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JKwASe4MvUuGgxdYSsSRYL1KrkxNFKErogREMAVRAas=; b=Qr1PuxoxfdYOK3FkQljJ70BBpc/XLCmEbQlhQ5G7Ekpxo4r/DT23hEQBHFfKmRIoZH DRcoG90UG964nKY86CL6Dww9Ktx3pOzIV5xquvVD1TQGdWDvvA8wsvH22+ZwXeoouvEm DQLGkxJ4NqABRw0QrkwXehDUNPg7oY7CrQ/LdPlCY5x00g51OJzUue9tUhXcsa21Oo/O 7zuhT4uOwD9d3K4vNCevKKwSC9BKomTrRtQI6q6j75uQF8iVZ4XksEQWrz2zhq3qTIBx OEK0Bav2RzSznrvHW4D8FSu8W88IUZhjBQm8+IrX2mUo5Vv8RoAs2RjNdO2ljyBl7Sw8 I+oQ== X-Gm-Message-State: ALoCoQnWFZip2hRui9mZTTGkhvUesSqsgOHdlFl3QAkJHbIJKVM0/dswmVYuwT3E48Ex0BwP2GLH53vkdaWZVuB3rytXpa5thwueZl7hLJzjrn5Qo3ErxRrluDJ1Gyb1jyPoKmSvuq2ocUMt5e93DrVCyB3Dvxr8Vd5L2jPZ23huR6ccVySF/6TW2o2vUWTIuIfnYJlp2Dga X-Received: by 10.194.22.36 with SMTP id a4mr21301917wjf.54.1422332705446; Mon, 26 Jan 2015 20:25:05 -0800 (PST) Received: from [192.168.1.163] (ip-78-45-139-138.net.upcbroadband.cz. [78.45.139.138]) by mx.google.com with ESMTPSA id x18sm450819wia.12.2015.01.26.20.25.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 20:25:04 -0800 (PST) Message-ID: <54C7131E.6060006@2ndquadrant.com> Date: Tue, 27 Jan 2015 05:25:02 +0100 From: Tomas Vondra Organization: 2ndQuadrant User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Why is PostgreSQL not using my index? References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 Hi, On 26.1.2015 17:32, Christian Roche wrote: > select * > > from mixpanel_events_201409 mp > > inner join mixpanel_event_list ev on ( ev.id = mp.event_id ) > > where ev.id in (3, 4, 5, 6, 7, 8, 9, 10, 11, 373, 375, 376, 318); > > > > Hash Join (cost=20.73..2892183.32 rows=487288 width=1000) > > Hash Cond: (mp.event_id = ev.id) > > -> Seq Scan on mixpanel_events_201409 mp (cost=0.00..2809276.70 > rows=20803470 width=949) > > -> Hash (cost=20.57..20.57 rows=13 width=51) > > -> Seq Scan on mixpanel_event_list ev (cost=0.00..20.57 > rows=13 width=51) > > Filter: (id = ANY > ('{3,4,5,6,7,8,9,10,11,373,375,376,318}'::integer[])) > > > > > > Both tables have been vacuum analyzed. Can we get EXPLAIN ANALYZE please, and maybe some timings for the two plans? Otherwise we have no clue how accurate those estimates really are, making it difficult to judge the plan choice. You might also use enable_hashjoin=off to force a different join algorithm (it may not switch to nested loop immediately, so maybe try the other enable_* options). The estimated row counts are quite near each other (410k vs. 487k), but the costs are not. I'm pretty sure that's because while the fist query has WHERE condition directly on the event_id column, the second one moves the condition to the 'list' table, forcing this particular plan. But as the condition is on the join column, you may try moving it back: select * from mixpanel_events_201409 mp inner join mixpanel_event_list ev on ( ev.id = mp.event_id ) where mp.event_id in (3, 4, 5, 6, 7, 8, 9, 10, 11, 373, 375, 376, 318); Of course, this only works on this particular column - it won't work for other columns in the 'list' table. regards -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance