Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1irVDw-0002NP-Qn for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Jan 2020 23:03:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1irVDv-0007qY-J3 for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Jan 2020 23:03:47 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1irVDv-0007qR-9z for pgsql-hackers@lists.postgresql.org; Tue, 14 Jan 2020 23:03:47 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1irVDq-0001lU-RN for pgsql-hackers@lists.postgresql.org; Tue, 14 Jan 2020 23:03:46 +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 00EN3dBC007615; Tue, 14 Jan 2020 18:03:39 -0500 From: Tom Lane To: Alexander Korotkov cc: Julien Rouhaud , Tomas Vondra , Nikita Glukhov , PostgreSQL Hackers , Thomas Munro , Marc Cousin Subject: Re: Avoid full GIN index scan when possible In-reply-to: References: <17590.1564685940@sss.pgh.pa.us> <19189.1564687723@sss.pgh.pa.us> <19438.1565209940@sss.pgh.pa.us> <20200106152155.uuungi2p776p5lbk@development> <29242.1578670290@sss.pgh.pa.us> <20952.1579027391@sss.pgh.pa.us> Comments: In-reply-to Alexander Korotkov message dated "Wed, 15 Jan 2020 01:47:30 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7613.1579043019.1@sss.pgh.pa.us> Date: Tue, 14 Jan 2020 18:03:39 -0500 Message-ID: <7614.1579043019@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alexander Korotkov writes: > On Tue, Jan 14, 2020 at 9:43 PM Tom Lane wrote: >> One thing I'm still not happy about is the comment in >> collectMatchesForHeapRow. v12 failed to touch that at all, so I tried to >> fill it in, but I'm not sure if my explanation is good. > I've tried to rephrase this comment making it better from my point of > view. It's hard for me to be sure about this, since I'm not native > English speaker. I'd like you to take a look on it. Yeah, that's not great as-is. Maybe like + * All scan keys except excludeOnly require at least one entry to match. + * excludeOnly keys are an exception, because their implied + * GIN_CAT_EMPTY_QUERY scanEntry always matches. So return "true" + * if all non-excludeOnly scan keys have at least one match. >> Also, if we know >> that excludeOnly keys are going to be ignored, can we save any work in >> the main loop of that function? > It doesn't look so for me. We still need to collect matches for > consistent function call afterwards. Ah, right. > I also had concerns about how excludeOnly keys work with lossy pages. > I didn't find exact error. But I've added code, which skips > excludeOnly keys checks for lossy pages. They aren't going to exclude > any lossy page anyway. So, we can save some resources by skipping > this. Hmm ... yeah, these test cases are not large enough to exercise any lossy-page cases, are they? I doubt we should try to make a new regression test that is that big. (But if there is one already, maybe we could add more test queries with it, instead of creating whole new tables?) regards, tom lane