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 1pQAhL-0002VO-1P for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 17:27:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pQAhJ-0001Wi-Vz for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Feb 2023 17:27:01 +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 1pQAhI-0001VP-Sz for pgsql-hackers@lists.postgresql.org; Thu, 09 Feb 2023 17:27:01 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pQAhE-0004fN-HO for pgsql-hackers@postgresql.org; Thu, 09 Feb 2023 17:26:59 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 705975C0144; Thu, 9 Feb 2023 12:26:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 09 Feb 2023 12:26:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1675963615; x=1676050015; bh=X NH7b2FYSF8MId83nASB+CZ7HyZ3Waj65KUaaE9VEAE=; b=hsOkRO8AKNy/snAgz T8/U8DtOMEkHSHQOs3A+wUB1RGofKI4QhDhQsEmhyCzchT+JdIuveQqAJ0vIfsUl 3PgyX99oDxsQVsbiB3Egv01aIQhcUDpchLIOYUJPBlcCkotzO8dPzJV21XpIsxF0 PsIr/sjmKrtuJOCryA9qboKe9245e8v5PMSlwaGQSlOu/XPBXMKSIgranboqd/gg bnSfIN0zv8gKp4vNVPgWPN9m5fMNdCxg4Oc6+oEU6x3aRvRnuRRHjdGJt9YNIg77 Y3Grz1Xn4Gvp2WIGhQGu5DKJL2q25NIsgjrim8pjJUGyolu+Qy9Ou6a9hD645LQX /C9vw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehfedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Feb 2023 12:26:54 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 427C29C; Thu, 9 Feb 2023 18:26:51 +0100 (CET) Date: Thu, 9 Feb 2023 18:26:51 +0100 From: Alvaro Herrera To: Dmitry Dolgov <9erthalion6@gmail.com> Cc: Peter Eisentraut , Sergei Kornilov , Michael Paquier , Marcos Pegoraro , vignesh C , Robert Haas , Zhihong Yu , David Steele , PostgreSQL-development , Greg Stark , Pavel Trukhanov , Tom Lane Subject: Re: pg_stat_statements and "IN" conditions Message-ID: <20230209172651.cfgrebpyyr72h7fv@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230209151226.nwt56axfcu5y3wpr@ddolgov.remote.csb> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Feb-09, Dmitry Dolgov wrote: > > On Thu, Feb 09, 2023 at 02:30:34PM +0100, Peter Eisentraut wrote: > > What is the point of making this a numeric setting? Either you want > > to merge all values or you don't want to merge any values. > > At least in theory the definition of "too many constants" is different > for different use cases and I see allowing to configure it as a way of > reducing the level of surprise here. I was thinking about this a few days ago and I agree that we don't necessarily want to make it just a boolean thing; we may want to make it more complex. One trivial idea is to make it group entries in powers of 10: for 0-9 elements, you get one entry, and 10-99 you get a different one, and so on: # group everything in a single bucket const_merge_threshold = true / yes / on # group 0-9, 10-99, 100-999, 1000-9999 const_merge_treshold = powers Ideally the value would be represented somehow in the query text. For example query | calls ----------------------------------------------------------+------- select * from test where i in ({... 0-9 entries ...}) | 2 select * from test where i in ({... 10-99 entries ...}) | 1 What do you think? The jumble would have to know how to reduce all values within each power-of-ten group to one specific value, but I don't think that should be particularly difficult. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge)