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 1rE59U-0047B1-L6 for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Dec 2023 10:10:41 +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 1rE59R-000WFN-Ec for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Dec 2023 10:10:37 +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 1rE59P-000WFF-QW for pgsql-hackers@lists.postgresql.org; Fri, 15 Dec 2023 10:10:37 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rE59L-00C7GJ-Vj for pgsql-hackers@lists.postgresql.org; Fri, 15 Dec 2023 10:10:35 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 861C25808F2; Fri, 15 Dec 2023 05:10:28 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 15 Dec 2023 05:10:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1702635028; x= 1702642228; bh=l23nQY5RYKV+cShaNnVj5hYXH/jGtF8vqn4qYjHorBE=; b=B Gtf6owGYchbW5Sv3OPg5i1JUZ7fTlIy9K6rQhbUqrsZHn3QAhgZNDiM6IAtlk/uD 7WD6qVT9MvEfIFskxlxWO3OQ3bn0vKCpefmRy5x/iIUqx49Nh7tb0NJgG8sPbpns J11L28NGC3RF95Uz51koJytTMlwLtnSZCkNsp/9n1gB1DyZQoF/3DbjX9QNfLt9r 1lURZ0CtrBqNklrCuGsK3DbuoaxIiy8nSCCfkGiahUtwOb/4dlhp0KUx9eTyBJLp +qIY5ae/gDcpBrhzP+J9wOrwcwKK2SOY7OGglCALlCaybaUdeDd3UhxeRbAph53M LiEABjtHqtbga+jJSav2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddtvddguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Dec 2023 05:10:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1702635024; bh=UuDZZ30CZC6Z8PRuykEl/qkOwnZz8cwnpm+3AbBh7Ac=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=If7t5V4Hpo7O1KTPc3orT1IdExVJP9KAOaUHwyOiuZnQcpmN4zKZUYaB3Rh20LLeL sP0D/FXe1PmNZfcSueDBpER8qN7A/gwm6ePeTf5wmQyljWMXWKqPyab2CBA5Il7v7Y B4BUPw/wuN/TvcluAlmMREn0ignJwewLUfTGhEmR+w5HQzjq3J96pFALlT+mo5CbEa cr54Fak9DQ5E9UWtHAd14h2kKkuO3RoOITza1ILjbhThoTiLPsZ/ZAJy7WEvZ6UskP wIKHJWU3DpSZDalbenFT0s/eynpu82/LvCMGWZ1iFTFWQ6dz8IrenX6em0wHArJcpI mcCoBEghaJ5WQ== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 05BB23B1; Fri, 15 Dec 2023 11:10:24 +0100 (CET) Date: Fri, 15 Dec 2023 11:10:24 +0100 From: Alvaro Herrera To: Masahiko Sawada Cc: PostgreSQL Hackers Subject: Re: Improve eviction algorithm in ReorderBuffer Message-ID: <202312151010.y64axdxuzcvi@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Dec-12, Masahiko Sawada wrote: > To deal with this problem, I initially thought of the idea (a) > mentioned in the comment; use a binary heap to maintain the > transactions sorted by the amount of changes or the size. But it seems > not a good idea to try maintaining all transactions by its size since > the size of each transaction could be changed frequently. Hmm, maybe you can just use binaryheap_add_unordered and just let the sizes change, and do binaryheap_build() at the point where the eviction is needed. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "No necesitamos banderas No reconocemos fronteras" (Jorge González)