Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpuni-0004wq-NP for pgsql-sql@arkaria.postgresql.org; Mon, 29 Jun 2020 14:30:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jpunh-0004fH-64 for pgsql-sql@arkaria.postgresql.org; Mon, 29 Jun 2020 14:30:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpung-0004fA-W5 for pgsql-sql@lists.postgresql.org; Mon, 29 Jun 2020 14:30:24 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpund-0002F5-KV for pgsql-sql@lists.postgresql.org; Mon, 29 Jun 2020 14:30:23 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 05TEUJ3H323667; Mon, 29 Jun 2020 10:30:19 -0400 From: Tom Lane To: Martin Handsteiner cc: Simon Riggs , "pgsql-sql@lists.postgresql.org" Subject: Re: AW: Optimizer Hint, to ignore limit and offset in optimizer plan In-reply-to: References: Comments: In-reply-to Martin Handsteiner message dated "Mon, 29 Jun 2020 08:10:34 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <323665.1593441019.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2020 10:30:19 -0400 Message-ID: <323666.1593441019@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Martin Handsteiner writes: > yes, this would exactly be the feature I was talking about. > enable_costlimit =3D true (default) | false > How high is the possibility, that this feature will find the way into th= e postgres db? Not very good, unless you can present a far more convincing use-case. If I understand your desire, it is that issuing the "same" query in different transactions would generate identical overall results despite varying the offset/limit so as to fetch different parts of that unchanging result. The problem with this is that whether changing the offset/limit changes the plan shape is just one of many reasons why you might not get a consistent result --- the most unavoidable being that other transactions might commit data changes. Moreover, you insist that you shouldn't have to use an ORDER BY to get these consistent results. Sorry, but SQL is *defined* to not produce consistent row ordering without ORDER BY. Changing that isn't a matter of some optimizer hint somewhere, it's a very fundamental thing in many places. I'd counsel taking another look at the suggestion made upthread to use a cursor WITH HOLD. regards, tom lane