Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sF46r-006XNQ-Ft for pgsql-bugs@arkaria.postgresql.org; Thu, 06 Jun 2024 03:48:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sF46q-00EYLm-Kk for pgsql-bugs@arkaria.postgresql.org; Thu, 06 Jun 2024 03:48:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sF46q-00EYLe-Bx for pgsql-bugs@lists.postgresql.org; Thu, 06 Jun 2024 03:48:16 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sF46n-000E11-K2 for pgsql-bugs@lists.postgresql.org; Thu, 06 Jun 2024 03:48:15 +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 4563m97d951330; Wed, 5 Jun 2024 23:48:09 -0400 From: Tom Lane To: David Rowley cc: Alvaro Herrera , Alexander Alexander , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18477: A specific SQL query with "ORDER BY ... NULLS FIRST" is performing poorly if an ordering column is n In-reply-to: References: <202405241003.uxtpwvtwcods@alvherre.pgsql> Comments: In-reply-to David Rowley message dated "Thu, 06 Jun 2024 15:29:33 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <951328.1717645689.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 05 Jun 2024 23:48:09 -0400 Message-ID: <951329.1717645689@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Fri, 24 May 2024 at 22:03, Alvaro Herrera w= rote: >> But the NOT NULL constraint could be dropped at any minute, so the >> system needs to know where NULLs would go if that were to happen. > In my understanding, the planner will hold a lock that will prevent a > concurrent session from doing ALTER TABLE ... DROP NOT NULL, so if the > planner were to do an optimisation such as this, I think it should be > safe. Can you explain where the hazard is? This has nothing to do with the planner. The question Alvaro responded to is whether the DDL definition of the index establishes which end nulls should go at. Which it does, independently of whether the table actually contains any nulls. Yes, we could possibly set things up so that an index with nulls last is considered to match a query that specifies NULLS FIRST if we know that the column is not-nullable. But I refuse to believe that this would be a good use of either development effort or planner cycles. AFAICS the problem is purely self-inflicted damage: why is the user specifying NULLS FIRST if he knows the column is not-null? regards, tom lane