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 1vGIRd-00BvdS-UR for pgsql-bugs@arkaria.postgresql.org; Tue, 04 Nov 2025 14:55:37 +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 1vGIRb-00ETJI-7s for pgsql-bugs@arkaria.postgresql.org; Tue, 04 Nov 2025 14:55:34 +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 1vGIRa-00ETHY-VU for pgsql-bugs@lists.postgresql.org; Tue, 04 Nov 2025 14:55:34 +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.96) (envelope-from ) id 1vGIRX-005wnv-2w for pgsql-bugs@lists.postgresql.org; Tue, 04 Nov 2025 14:55:33 +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 5A4EtSZ0517271; Tue, 4 Nov 2025 09:55:28 -0500 From: Tom Lane To: "David G. Johnston" cc: "jinhui.lai@qq.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #19103: Canceled INSERT statement can still influence the performance of subsequent SELECT statement In-reply-to: References: <19103-0e4f007453331d2b@postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Tue, 04 Nov 2025 08:26:01 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <517269.1762268128.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Tue, 04 Nov 2025 09:55:28 -0500 Message-ID: <517270.1762268128@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Tuesday, November 4, 2025, PG Bug reporting form > wrote: >> Thanks for reading my report. Here, I find a performance issue. I have >> found a performance issue where a canceled INSERT statement appears to >> negatively impact the performance of subsequent SELECT queries. > This doesn’t feel like a bug. It is not. The reason ROLLBACK is essentially free in Postgres is that some of the ensuing cleanup work gets done during subsequent table accesses. Some other DBMSes do that differently, but that's our choice and we're not likely to revisit it. > Temporary tables are nice for this kind of flow. Don’t touch production > tables until you know what you are going to insert is going to stick. Yeah. Frequently rolling back large data modifications is a performance anti-pattern no matter what the underlying implementation does. regards, tom lane