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 1h6j0Y-00044y-Fd for pgsql-committers@arkaria.postgresql.org; Wed, 20 Mar 2019 21:44:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h6j0W-0006Hs-Vg for pgsql-committers@arkaria.postgresql.org; Wed, 20 Mar 2019 21:44:20 +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 1h6j0W-0006E2-Ch for pgsql-committers@lists.postgresql.org; Wed, 20 Mar 2019 21:44:20 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6j0T-00011v-OU for pgsql-committers@lists.postgresql.org; Wed, 20 Mar 2019 21:44:19 +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 x2KLiF6Z017605; Wed, 20 Mar 2019 17:44:15 -0400 From: Tom Lane To: Peter Geoghegan cc: pgsql-committers Subject: Re: pgsql: Make heap TID a tiebreaker nbtree index column. In-reply-to: <16667.1553116435@sss.pgh.pa.us> References: <13999.1553105283@sss.pgh.pa.us> <24277.1553114810@sss.pgh.pa.us> <16667.1553116435@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 20 Mar 2019 17:13:55 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17603.1553118255.1@sss.pgh.pa.us> Date: Wed, 20 Mar 2019 17:44:15 -0400 Message-ID: <17604.1553118255@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > A preliminary check-world run finds no places where the output changes, > but I've not tried this with SELinux yet. After trying it (against yesterday's sources) on my SELinux-capable machine, I see no evidence that we need any output ordering changes at all if we go this route. This is probably unsurprising considering that the old btree code used to provide mostly-reverse-insertion-order scan order. regards, tom lane