Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCEI3-00065f-6q for pgsql-performance@arkaria.postgresql.org; Sun, 21 May 2017 00:00:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dCEI2-0004E2-Pj for pgsql-performance@arkaria.postgresql.org; Sun, 21 May 2017 00:00:06 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dCEI1-0004D1-SZ for pgsql-performance@postgresql.org; Sun, 21 May 2017 00:00:06 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dCEHz-0003kO-Hm for pgsql-performance@postgresql.org; Sun, 21 May 2017 00:00:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v4L002s1003304; Sat, 20 May 2017 20:00:02 -0400 From: Tom Lane To: Zac Goldstein cc: pgsql-performance@postgresql.org Subject: Re: Index not being used on composite type for particular query In-reply-to: References: Comments: In-reply-to Zac Goldstein message dated "Sat, 20 May 2017 16:33:16 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3302.1495324802.1@sss.pgh.pa.us> Date: Sat, 20 May 2017 20:00:02 -0400 Message-ID: <3303.1495324802@sss.pgh.pa.us> 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 Zac Goldstein writes: > This uses the index: > ... > But this doesn't: > EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM shot > WHERE lower(shot.matchsecond) <@ ((shot.matchsecond).match_id, > numrange(5, 10))::matchsecond_type; Well, yeah. After inlining the SQL functions, what you have is > Filter: ((((matchsecond).match_id)::integer = > ((matchsecond).match_id)::integer) AND > ((numrange(lower(((matchsecond).second)::numrange), > lower(((matchsecond).second)::numrange), '[]'::text))::numrange <@ > ('[5,10)'::numrange)::numrange)) and neither half of the AND has the form "indexed_value indexable_operator constant", which is the basic requirement for an index condition. We're a little bit permissive about what "constant" means, but that most certainly doesn't extend to expressions involving columns of the table. So the first clause loses because it's got variables on both sides, and the second loses because the LHS expression is not what the index is on. You could build an additional index on that expression, if this shape of query is important enough to you to justify maintaining another index. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance