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.96) (envelope-from ) id 1vsPN0-004D3t-0b for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 18:00:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vsPMx-00BHvh-2m for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 18:00:20 +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.96) (envelope-from ) id 1vsPMx-00BHvY-1f for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 18:00:19 +0000 Received: from fhigh-b6-smtp.messagingengine.com ([202.12.124.157]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vsPMv-00000001EXc-1luW for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 18:00:19 +0000 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id 01EF47A069C; Tue, 17 Feb 2026 13:00:15 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Tue, 17 Feb 2026 13:00:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm2; t=1771351215; x= 1771437615; bh=bfTt52qjtktpZ4nOcM4CSbkWRB1LNakOTyHjBIaJb/g=; b=k aioKiKq+lT2rE2bLOav7T8+bd3MBMZ8w7vez9z1rkHPsBlYQaFHPGzzwAV6WIeEP 6NzcIkWIHNz1y2oIFT4kMYEDlSXzen1qRWJ5btIzt2cisi/yqW+pt90n2ugxWJIj +3rseMYdDsj0YhJ38Bu9xRiP5FizZH/VEbXZahafCJj4L9st/yLkmXz4F70IUR9n fidcqc6/2Wj5S3zhhTwB+p6rzFf1yXiLvzrai1NgcpdZWW6evawXg7cWyKlT5itz ngXjt2+E9FzOQwPTElzXiifJKlQNu5PRZJfx5JiZapjldYzGkFoj8lli9R/fTsxY QY6oYwm6cFRIFuwHSTTZQ== 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-sender :x-me-sender:x-sasl-enc; s=fm3; t=1771351215; x=1771437615; bh=b fTt52qjtktpZ4nOcM4CSbkWRB1LNakOTyHjBIaJb/g=; b=BiJwSDKhymZ6XmLVE rb6//S+mcQdmDcu2OKqgmzyjHB0YeZnxDJXxd8C3uIEYLQvxyd2Rq9K3o27y/cfc IOigszCXK+zIFu3XbFKUsyaFBajpYb+Bwpi6Mqox1pNAm8aWUP8uPJWUSUtBHc5b vradt5SSJ1ix5Wt5Oe+uAMWq6x3fW3Rsp1evZ72MUv2BNOxC0YLLMOjeY3wMLOCh zlCRv4Ca7WLa4+J+sPYD3V+jukLD1qOm3xNZMAMgusviVbtqlx93ecSUm6KfP+qn ZGEZURChypCpFHRMP2G8obFrk0wXZB3yllZ0QcOUO2hr0xlkyKu/RpbfvXHToMz9 DrAZA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvddtgedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheplmhlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvqeenucggtf frrghtthgvrhhnpeetuedvheffkeevgfeuheevteevkefggedttdeufeeuheduuddthfef fffhjeefffenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgv sehkuhhrihhlvghmuhdruggvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopegrnhgurhgvshesrghnrghrrgiivghlrdguvgdprhgtphhtthho pehfrggsrhhiiihiohhmvghllhhosehgmhgrihhlrdgtohhmpdhrtghpthhtohepphhgsh hqlhdqhhgrtghkvghrsheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Feb 2026 13:00:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1771351212; bh=nF+EAnTDm04qKHL8azouBrODc5Wh/DfGu/uyDIHuVgQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=nv9gkKQrBl/pRMR88heahbJC1tWaoqavDpP73oRqtmsabexIKYROugzq7kHadB9Kg PLLG6q9mwv0g9Ia/nyk4oidlPCGvUQUTVmIrhqdAigk1qY2T37/pjL0aaVLmMA4t10 dxzStwODRQsgs2dEiwnHss27XjCohKJiIfe5zkYErCkLkyimfQxb3d4np2s+qX5KNE xIXZ02KJ9p2hBxanF4tOd45ba1cN0cdOqAJL+FcSR20AVVXBb6HPMAWfipKRaHv6aB gd5RB67zZ5TCbo0H+zic7A47y2OnzPMiXKRHz4LKMGLDTz9DlGqmcgeuva0h/nvMrn yRllgQnfxnIxA== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 995DB7A; Tue, 17 Feb 2026 19:00:12 +0100 (CET) Date: Tue, 17 Feb 2026 19:00:12 +0100 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Andres Freund Cc: =?utf-8?B?RmFicsOtemlv?= de Royes Mello , Pg Hackers Subject: Re: make ExecInsertIndexTuples arguments less bad Message-ID: <202602171751.54sfencar22w@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 2026-Feb-16, Andres Freund wrote: > Personally I'd move the flags to before the slot and the estate before slot > (because it seems like options should come before the data and the most > frequently changing arguments should be later on), but that's an extremely > minor detail. Good point, I pushed like that. > I'm mildly surprised about using bits32, we seem to be more widely just using > uint32 or such. I find a lot of the typedefs in c.h much more noise than > useful. But also, whatever. Yeah, I dunno, maybe we can retire those, but to me they say more explicitly that the variable is not a number but rather a set of bits. It doesn't make any actual difference, of course ... I've tried to prod others to use bits32 instead of uint32 and have had little (read: none) uptake, hah. > > There might be places in executor.h to reuse the f831d4accda0 thingy, > > but this is probably not it. > > FWIW, when passing <= 6 values, passing the arguments by reference in a struct > (rather than passing the struct by value), is likely to lead to less efficient > code. Noted. > > @@ -943,11 +946,16 @@ ExecSimpleRelationUpdate(ResultRelInfo *resultRelInfo, > > conflictindexes = resultRelInfo->ri_onConflictArbiterIndexes; > > > > if (resultRelInfo->ri_NumIndices > 0 && (update_indexes != TU_None)) > > + { > > + bits32 flags = EIIT_IS_UPDATE; > > + > > + flags |= conflictindexes != NIL ? EIIT_NO_DUPE_ERROR : 0; > > + flags |= update_indexes == TU_Summarizing ? EIIT_ONLY_SUMMARIZING : 0; > > I'd just make these ifs, this is somewhat hard to read. Changed that way. Thanks for reviewing! -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Los cuentos de hadas no dan al niño su primera idea sobre los monstruos. Lo que le dan es su primera idea de la posible derrota del monstruo." (G. K. Chesterton)