Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g0VdK-0002Ru-A2 for pgsql-bugs@arkaria.postgresql.org; Thu, 13 Sep 2018 17:42:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g0VdG-0001QT-CY for pgsql-bugs@arkaria.postgresql.org; Thu, 13 Sep 2018 17:42:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g0VdG-0001QM-65 for pgsql-bugs@lists.postgresql.org; Thu, 13 Sep 2018 17:42:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g0VdC-0007ea-O5 for pgsql-bugs@postgresql.org; Thu, 13 Sep 2018 17:42:21 +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 w8DHgAwn012109; Thu, 13 Sep 2018 13:42:10 -0400 From: Tom Lane To: =?utf-8?B?TWFyZWtzIEthbG5hxI1z?= cc: Victor Yegorov , "pgsql-bugs@postgresql.org" , =?utf-8?B?TcSBcmlzIFJ1Y2lz?= , =?utf-8?B?UMSBdmVscyBLb3LFvnM=?= Subject: Re: PostgreSQL 10.0 SELECT LIMIT performance problem In-reply-to: <803c5396974a42849ebec62bfa47f2c8@datakom.lv> References: <7419b7a3a21d4f1c8509178a071ec636@datakom.lv> <803c5396974a42849ebec62bfa47f2c8@datakom.lv> Comments: In-reply-to =?utf-8?B?TWFyZWtzIEthbG5hxI1z?= message dated "Thu, 13 Sep 2018 10:03:49 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12107.1536860530.1@sss.pgh.pa.us> Date: Thu, 13 Sep 2018 13:42:10 -0400 Message-ID: <12108.1536860530@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk =?utf-8?B?TWFyZWtzIEthbG5hxI1z?= writes: > But we are using value indexes not a json index: > CREATE INDEX idx_oss_alarms_dn > ON oss_alarms > USING btree > ((jdata ->> 'dn'::text) COLLATE pg_catalog."default"); I think you're outsmarting yourself by including those COLLATE clauses. They don't do anything, since they're just selecting the default behavior --- but they're enough to make the planner not realize that stats collected on the index expression would be applicable to a plain reference to oss_alarms.jdata ->> 'dn'. In general you want the index expression to be spelled exactly the same way that you refer to the value in queries, else the system may not realize it's relevant. regards, tom lane