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 1i5xdS-0007bQ-Od for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 19:41:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5xdQ-0001c4-TU for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 19:41:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5xdQ-0001Va-Bx for pgsql-hackers@lists.postgresql.org; Thu, 05 Sep 2019 19:41:36 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1i5xdN-0002V9-Rg for pgsql-hackers@postgresql.org; Thu, 05 Sep 2019 19:41:35 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 2EECB1DD3; Thu, 5 Sep 2019 15:41:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 05 Sep 2019 15:41:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=JBzoLu2NTSXLtL2JLPyqdfTRzpyvoW1yj5W9HXoefvU=; b=F/uIsATA xgGMVDERdJEfVw/KBWbPJRTZptcp7FWu51MwqvRcFFmvqK6tYqnOeCAEbvcx68eg K1v4nb4RujdiUVpZa4DyqEQ/9uSCu0yUZ8Sr45AlU4iBPT7jqwaSVE8fZkxwW1R1 PUmiHwKu5E2+7jI0NYmqUh4mCWFDMZYPNkjmY9iTnRDCdjnjb/aktZpOs/gmwl4E nHlyeEiloth4RSzJ2AbgWwtLeDAm/BL6jKjV4szubLJ2k8hCu7L2dGgRpCDhVgu3 kDtBlQK7t1VUCnT4fyoPnQ2rIoBHsjzCrfZ9vuOnzxKvP431GsbYntx6PDqJUC5b JAyK6UW4lSp6Pw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejjedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcufhhrohhmucdvnhgusfhurggurhgrnhhtuceorghlvhhhvg hrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqnecuffhomhgrihhnpedvnhguqhhurggu rhgrnhhtrdgtohhmnecukfhppeduledtrdduvddurddvledrfeenucfrrghrrghmpehmrg hilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: from nimloth.alvh.no-ip.org (unknown [190.121.29.3]) by mail.messagingengine.com (Postfix) with ESMTPA id 5EDEAD6005A; Thu, 5 Sep 2019 15:41:30 -0400 (EDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 82C1A123A72; Thu, 5 Sep 2019 15:41:28 -0400 (-04) Date: Thu, 5 Sep 2019 15:41:28 -0400 From: Alvaro Herrera from 2ndQuadrant To: Dmitry Dolgov <9erthalion6@gmail.com> Cc: Floris Van Nee , Kyotaro Horiguchi , "jesper.pedersen@redhat.com" , David Rowley , Thomas Munro , James Coleman , Rafia Sabih , Jeff Janes , Peter Geoghegan , Tomas Vondra , Thomas Munro , Bhushan Uparkar , PostgreSQL-development , Alexander Korotkov Subject: Re: Index Skip Scan Message-ID: <20190905194128.GA10752@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Sep-05, Dmitry Dolgov wrote: > Here is the version in which stepping between the pages works better. It seems > sufficient to fix the case you've mentioned before, but for that we need to > propagate keepPrev logic through `_bt_steppage` & `_bt_readnextpage`, and I > can't say I like this solution. I have an idea that maybe it would be simpler > to teach the code after index_skip to not do `_bt_next` right after one skip > happened before. It should immediately elliminate several hacks from index skip > itself, so I'll try to pursue this idea. Cool. I think multiplying two ScanDirections to watch for a negative result is pretty ugly: /* * If advancing direction is different from index direction, we must * skip right away, but _bt_skip requires a starting point. */ if (direction * indexscan->indexorderdir < 0 && !node->iss_FirstTupleEmitted) Surely there's a better way to code that? I think "scanstart" needs more documentation, both in the SGML docs as well as the code comments surrounding it. Please disregard my earlier comment about FirstTupleEmitted. I was thinking that index_skip would itself emit a tuple (ie. call some "getnext" internally) rather than just repositioning. There might still be some more convenient way to represent this, but I have no immediate advice. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services