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 1ga6gw-0004Wm-Sy for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Dec 2018 22:21:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ga6gu-0005uO-Ib for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Dec 2018 22:21:16 +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 1ga6gu-0005uH-Bd for pgsql-hackers@lists.postgresql.org; Thu, 20 Dec 2018 22:21:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ga6gq-00044n-VD for pgsql-hackers@lists.postgresql.org; Thu, 20 Dec 2018 22:21:15 +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 wBKML7r5008470; Thu, 20 Dec 2018 17:21:08 -0500 From: Tom Lane To: Edmund Horner cc: David Rowley , tomas.vondra@2ndquadrant.com, PostgreSQL Developers Subject: Re: Tid scan improvements In-reply-to: References: Comments: In-reply-to Edmund Horner message dated "Tue, 27 Nov 2018 21:16:46 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8468.1545344467.1@sss.pgh.pa.us> Date: Thu, 20 Dec 2018 17:21:07 -0500 Message-ID: <8469.1545344467@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Edmund Horner writes: > [ tid scan patches ] I'm having a hard time wrapping my mind around why you'd bother with backwards TID scans. The amount of code needed versus the amount of usefulness seems like a pretty bad cost/benefit ratio, IMO. I can see that there might be value in knowing that a regular scan has "ORDER BY ctid ASC" pathkeys (mainly, that it might let us mergejoin on TID without an explicit sort). It does not, however, follow that there's any additional value in supporting the DESC case. regards, tom lane