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 1taOtl-001WlV-9z for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2025 00:47:13 +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 1taOtj-008fJ1-4n for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2025 00:47:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1taOti-008fIs-Ra for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2025 00:47:10 +0000 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1taOtg-000okS-2U for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2025 00:47:09 +0000 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 32E292540226; Tue, 21 Jan 2025 19:47:08 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Tue, 21 Jan 2025 19:47:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1737506828; x=1737593228; bh=Bp+YU2fA1d 4bAhkwNIi9+HDQRqYSd6hHLj+9DmRwFdQ=; b=reXoW9cJ8+d/HO6Ddso1LFj9Cu 4Vh/MzmSQsxKiEdQ7B5Dtb31j1sQm3GvfisbjPHz3uuqCGS+LEKqCahinXtr1S0l EMsBgGy7bMHtytn3LcxPjVbWOMnOeKXlxO4vxXHsKXAidcHujpkC1HCXwhP5PCGv Qda2expQzYNZkMiVWhQBCfmnYrn8CCjpYizicObZNQPVJen6Js0KZ+dVTI3S7shG ZpvRyuIqQQVrp5yZ9N61qNFHMVlFsXjzSxjKjxR8F10MFgeqExBYbPRMQs3sH+51 9NOor3hHoks/QgC9gWiH8Nu5868Tzy3s4UXdQ1Fw4UMbkzEXPXo1oTP0fpzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1737506828; x=1737593228; bh=Bp+YU2fA1d4bAhkwNIi9+HDQRqYSd6hHLj+ 9DmRwFdQ=; b=hzQOfazwd0Au4/BUrVNUFF/Gg9yIQpMRHhOupS7u98nXyk8hIFr 8dSAOJ3ZqMxO2TWCy9oPeo4GaH9fA7hNttCw0dOHIJ8wXoClWSayVXChMGxGU2Xj b7vr4M0Xz9HG+Yfun8GrDNQhI9uOIdUZ0Ikvxa8UgQ2gCix8pwn1PwCIonKY4Mob 147iwAifaa0xMU8zmS+qmu1OUd8V9zrPqAQY9FnqkV+dgH9C8dxzScZ1Xtd8UpG/ 8TRVnlL0dte1eyQ/LdE56M3ldA7LIZ7odnE/5k6siFgh4BXA7UtH1e1dVdlcnXX6 55Otg/w0g9ctY7yGsJDjAA7sMUvs1FVnzmQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejfedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnegfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvvefukfhf gggtuggjsehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruc eomhhitghhrggvlhesphgrqhhuihgvrhdrgiihiieqnecuggftrfgrthhtvghrnhepteel ieefudffhffhtdetleeggeegfffhkeeuveetiefgudduvedutefggeeivdejnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhes phgrqhhuihgvrhdrgiihiidpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtoheplhhukhgrshesfhhithhtlhdrtghomhdprhgtphhtthhopehpghhs qhhlqdhhrggtkhgvrhhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrghdprhgtph htthhopehmrghrkhhosehpghgrnhgrlhihiigvrdgtohhmpdhrtghpthhtohepshgrmhhi mhhsvghihhesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Jan 2025 19:47:05 -0500 (EST) Date: Wed, 22 Jan 2025 09:46:53 +0900 From: Michael Paquier To: Lukas Fittl Cc: PostgreSQL Hackers , Marko M , Sami Imseih Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mu6spM7cVlRq37L/" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --mu6spM7cVlRq37L/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 02, 2025 at 12:46:04PM -0800, Lukas Fittl wrote: > Inspired by a prior proposal by Sami Imseih for tracking Plan IDs [0], as > well as extensions like pg_stat_plans [1] (unmaintained), pg_store_plans > [2] (not usable on production, see notes later) and aurora_stat_plans [3] > (enabled by default on AWS), this proposed patch set adds: 0002 introduces this new routine to delete all the entries of the new stats kind you are adding: +void +pgstat_drop_entries_of_kind(PgStat_Kind kind) +{ + dshash_seq_status hstat; + PgStatShared_HashEntry *ps; + uint64 not_freed_count =3D 0; + + dshash_seq_init(&hstat, pgStatLocal.shared_hash, true); This is the same as pgstat_drop_all_entries(), except for the filter based on the stats kind and the fact that you need to take care of the local reference for an entry of this kind, if there are any, like pgstat_drop_entry(). Why not, that can be useful on its own depending on the stats you are working on. May I suggest the addition of a code path outside of your main proposal to test this API? For example injection_stats.c with a new SQL function to reset everything. +static void +pgstat_gc_plan_memory() +{ + dshash_seq_status hstat; + PgStatShared_HashEntry *p; + + /* dshash entry is not modified, take shared lock */ + dshash_seq_init(&hstat, pgStatLocal.shared_hash, false); + while ((p =3D dshash_seq_next(&hstat)) !=3D NULL) + { + PgStatShared_Common *header; + PgStat_StatPlanEntry *statent; Question time: pgstat_drop_entries_of_kind() is called once in 0004, which does a second sequential scan of pgStatLocal.shared_hash. That's not efficient, making me question what's the reason to think why pgstat_drop_entries_of_kind() is the best approach to use. I like=20 the idea of pgstat_drop_entries_of_kind(), less how it's applied in the context of the main patch. Mixed feelings about the choices of JumblePlanNode() in 0003 based on its complexity as implemented. When it comes to such things, we should keep the custom node functions short, applying node_attr instead to the elements of the nodes so as the assumptions behind the jumbling are documented within the structure definitions in the headers, not the jumbling code itself. -- Michael --mu6spM7cVlRq37L/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmeQP/0ACgkQnvQgOdby QH0Xzw/+Ng6bqeemJ90PzZLefazs7BkhgmwXCZzSPu/1Ty9GPqnk0Gxfe4TdRlZ8 gYGeRqFXcRTN6uQk/gJUYOlARMCsErLfaI3nxqYNyPfc3RU+833OOrKrABN4w+do yje6FNupFHkl/DRb1vLJbm3gIJD854GkyKqgF9hPpCKwzf63pk3rZ3zeVRXBhDzr oN0NG/+E7Yasl9jIa0Vmtvi4kRFLA8kV/qhz7K+C9jJtt6h4TCdUqYB7POXdGjsH PSCryImCyt1Wqo3QbiP/aHTSZoQ5e3XMBZkZEQYJYqpcUKMZQMDd4+B4LZYNOI+d ijF1fsHoLYIj2WNZdJrZsxMCy8Z3lkFyk8D6v90oNV6Id2KvfgtdTC+ZhR2IuyUD y9NHcdkAf/Mre38vDNJQu547kgrfN1LmtnY6S8lAqi+KbNj1jvAZOaEMaG28V+eS q86t5hW52VaO+PP7AdB69FcudyLA7vDoV/mki9KtaSGLyALE0HOBTFqw+5vwrAZH QLTCZPyqTXtenAzo6yT+U8jeiwvPQqVhLn3adx9G0S8fTrQ7K1fblhAFzj/Z5y6I dUGMbAS+jyBRbYiinKIe13pLT3L1cYvHt/1i5w7ziTAdH8y1zw/ktiZJwHBIIEZd Yi0fscW7HxXaKacqbWK+8LMAmlVlaT3FEHjFi8CHdo7XIkikY/Q= =myPW -----END PGP SIGNATURE----- --mu6spM7cVlRq37L/--