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 1w8LA1-000RFA-34 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 16:44:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8LA0-00715X-1D for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 16:44:48 +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.96) (envelope-from ) id 1w8L9z-00715O-33 for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 16:44:48 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w8L9y-00000000DPn-0NaN for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 16:44:47 +0000 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b936331786dso114955766b.3 for ; Thu, 02 Apr 2026 09:44:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775148285; cv=none; d=google.com; s=arc-20240605; b=QZAJEHnJY2z5hisEZH0hVeMpXxGvtVRSfONeyAK/xXE5sX7Blkr4N8YoDvc00DiyU9 zBF/gU/SSc70GloLQJjYFNoILhCbC0cURII4dxL/31cMFfvPAXvDC0ILvTLBlNpkwJQx NAGkgRMoeetsaGzn0OXIq7I+DzFnAqzSkRsAdA5DkrGqxcFNWDbYHCu2LeqrMC0EEBSx 2i22LZWNyTiF0cdzOONdMgKkxsbopEgUCkB4qVCm2HTWDQRIr/BEqKVrMdV9z+d7WVAv 5FBfqE00kTp2HUDNlqT1GfLaL52BzcZClZrH/pInyb/C3PQbzR7H8z0RSUfGrmumepA+ WbKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/OTM6WK48JoVnea3Y5f9TdrcGcSDrAzvC84xJeMDkd8=; fh=3PYrmal3jqBz9b1ZMxdoyFM32tTTVCU/syOaECvIiJ4=; b=JAuST50IyCo2fRV34CsfbYpljeZBjcmbZYjyiUs//s6Ak/CWE9SO/245pCn91/GZLd ++BtCMBu13B+SAp/S8eCOJ7ahUHeoEjD6miaN13TQc2JhWlfEbjfgarv8wyMU/7DZvW0 f7Vjrloe6QPiQ1JuE+PXlkRv1mqBg9Ci8UTvkxSa0UKKE5q3V6atmvn2IkLpMd0hFxXN qBJKJfTImGX1gBeY6lDogypVkP+WF8c91IDY1EPq9GS/H7LFdSoSYBOgezanooISfSK7 9Uoz8Pq50Cvrmfwc6tJYvQGbI/VVo1SyEmOVIvLl63Kem+jNzmF83wcIxKmfg9PCVJ1p yB1w==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775148285; x=1775753085; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/OTM6WK48JoVnea3Y5f9TdrcGcSDrAzvC84xJeMDkd8=; b=PWNv1LjShojj2QpuKqiluYzVPsCh+8TG6BtjHbX3+zKLDPQHbelcDmCKFDJqPtLzKD 0hdI6RAjoxSVSbysfLy8eI11z/8qHcTcVCqe6frQUICmmKFoZy471Th9I/rx6/kzvBG/ Ve1FFJF1RXaVB2k5WGrwUlUPcyIEiteT/XaQvLeDq3MDFce8O9jxpQsxDNt+lPrhpk2p Ot3Ws2SJdEzPydD4N+6d4ssJtn9X1/IU8NlEuu4sSes1XRajiLMDoPGRESoTvG5hnk/z i3FakOskThl18UZj1EZtNHwp8UDnRoXB/TPk2JlhyX16hD64IdGibM310yG/xghrgbW7 z0xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775148285; x=1775753085; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=/OTM6WK48JoVnea3Y5f9TdrcGcSDrAzvC84xJeMDkd8=; b=TIPPtw4g1hIsuLDRT8tbDkvd8+FguWCLgsVhuhPLuu8N5r4pWpJ0BS4QeA5MrbXw6h 0PqxeBf2a6w90bJ4Uygb2bABx+yYC5XqbjBGov+uT2J79nz+7vB+178KwtHTnb86ahwz sTH+WHSXIN/WhVWqTcoEzqkCd7mPEaeJcZI+PAW6mou+S8Sw1c9esu2ydimhTxpsn4QV INeIuKrbVw2zh52Twsk6ydg/AIEXsjZ+AdD4uhj+64SbCt19zfJT+kaObgWs9p34OjSf A4zFomuw/Kh4AEa8/FmyJFspM0pZOpYuf5pGbU9NzKihWrlwbPTWooov26JooGsm9LiI P2/Q== X-Forwarded-Encrypted: i=1; AJvYcCWwfsMGnCzQvTE/Slnsdd3dMnGDY3RdYVJE6EteQJObt+pOS9lOdlEEVO8LrWUf9e/6OMXlf1mxRNV5i8Ff@lists.postgresql.org X-Gm-Message-State: AOJu0YxQpvh/ctHi3oJkFQQXcVeBk76UizESiulsr9fEzD9PHC6lX0hD ZiyVjGObNXbKKtbXjnozbSpeFgs4atm8AVTmFlEg9DlZS2xMVz+djWuxDK3RHlWSbGWtTBZJsCQ DJAYizx3Hxv+ICOrtVxpedcZ+aHr/SLU= X-Gm-Gg: ATEYQzxgYmFj7y1955OUb8MCruqTonUB2HmkyWunGAZ08HCYews7EXgEHm6Wn4l3cSG UpcNcrA14yDXcSZUIpKHQ1gg0PXXMMNlO++3hRwOKLTkxv63HrkWeTecPE83RJlYLUb3qchxE0l s+kv+lzkUkAVOP+TX8qMt8VaBgIw25xRrPPJgo0RP8BaMjgkrShsbuHheRL/LxZ0aHOz5sVhHGc Z1YQlRC0QxVbI/0SUAwjZPiLNJM210g0L22htUZfERg1vS5craqJ/IYhvhIaPz0vLVv59QQuq7H tBeSHy0nsVLF0UKSUAJVa2+Ydg2MTI+MBoqEfk4= X-Received: by 2002:a17:907:96a0:b0:b98:8cc4:4abb with SMTP id a640c23a62f3a-b9c3ef8ba96mr249648866b.23.1775148284509; Thu, 02 Apr 2026 09:44:44 -0700 (PDT) MIME-Version: 1.0 References: <1136161.1769654478@sss.pgh.pa.us> <1299934.1773938807@sss.pgh.pa.us> In-Reply-To: From: Robert Haas Date: Thu, 2 Apr 2026 12:44:32 -0400 X-Gm-Features: AQROBzDDusi76F0bDwXCoCpCAM0eDG7W4ODETwqJz4X6SZten_e4EYO-16zMLQA Message-ID: Subject: Re: pg_plan_advice To: Lukas Fittl Cc: Jakub Wartak , Tom Lane , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Apr 1, 2026 at 2:34=E2=80=AFAM Lukas Fittl wrote: > Is there a reason you didn't use GetNamedDSA / GetNamedDSHash for the > other allocations? (which we have as of fe07100e82b09) I'm under the impression that GetNamedDSA and GetNamedDSHash exist for the purposes of making it easy for extensions to coordinate with each other across backends, rather than being something you're supposed to use to improve observability. I think it's potentially good for there to be a way to see the size of every DSA that exists in the system, but this clearly isn't that, because none of the code in src/backend uses it when creating DSAs. You might argue that DSAs for short-lived things like parallel query or parallel VACUUM don't need to be tracked like this (which seems arguable), but they are also used for long-lived contexts in the logical replication launcher, by LISTEN/NOTIFY, by the shared-memory statistics collector, and in GetSessionDsmHandle(), and those places don't use GetNamedDSA() either. Architecturally, I don't like the idea of replacing "having a pointer to an object" with "being able to look up that object by name". I think it's good design that pg_stash_advice creates one structure that serves as a sort of root and then hangs everything else off of that. I admit that leaves me not knowing quite what to do about the problem of knowing how much memory it's using, though. Adding a function just to return size information seems a little clunky, but it might be the right idea: it could for example return a count of stashes, a count of entries, the total length of the entries, and the allocated size of the DSA. --=20 Robert Haas EDB: http://www.enterprisedb.com