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 1twuBq-000s35-2a for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Mar 2025 02:38:54 +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 1twuBn-00DqEq-5o for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Mar 2025 02:38:51 +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 1twuBm-00DqEh-Ru for pgsql-hackers@lists.postgresql.org; Tue, 25 Mar 2025 02:38:50 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1twuBk-000zTJ-29 for pgsql-hackers@lists.postgresql.org; Tue, 25 Mar 2025 02:38:50 +0000 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-30c461a45f8so51134731fa.1 for ; Mon, 24 Mar 2025 19:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742870327; x=1743475127; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lB8A31tJFlN4szwaJXwYPsbsHx2jmyhoCVKgJ3OPJOo=; b=JBr3avqaH+9SOHhhfeigB4ecNU+fbBHua7OVTkFADEFBx8vqwNM2kH+Vd39DVnC9RM X5EAxRb1Y8mZ1RSw+EBkCNuc5GlB98DMbLdfoTxYVmi5kC3M/YSe2l9J4Q3AoAXMg6CM WZDCNoApHfxLQtQknmeWasdWh5mm2F3SSFyS1IfImI1KFKnqb3QRMKuspJ81kSyZSPCN ksAM4hiL6T8iNQdEx26oZUl9JM1P1xigZT0NK+svH9ZLBKH24Pns6waFsyEQrhNwBQOX rYbxrxSr9TFkjLSNajREHYggEAU5uqAsQze10Z+sPN/gPmn4HYJYpWYWHVouf07uupAe vTRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742870327; x=1743475127; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lB8A31tJFlN4szwaJXwYPsbsHx2jmyhoCVKgJ3OPJOo=; b=Pis/rwixTL4JkiMGMm8g+Zt0MbpsV1n2bzH9EUvKnoR/EwHfdI1VB7w0Gp5qJTq2Mq fqRlAZseLiQb0hvqO05f1keNfqxF2zCnIDL7FV84+PU9+jdAoYTOR224RbD+wd8dpVOW 5vr2JRODktUaIZ7kXxPT+bgLboJvGOYGCcETVLC/iKssv2FN+kOMcOB19s8je0bkqrOP ZBGxdNJUrEtDxKO474adeolYVpO9o76s6FL+5YOd7P+s6tuoW6Ciima63PCJd2AVoQSe aX0Y2vMCb++90F0AeHX5iTZwt/1BKf9CyRw2ZtO3blAg941K/Sz3Rd52jeVh+NhQAj1h nBRQ== X-Forwarded-Encrypted: i=1; AJvYcCVjSUqBY1q5TQpgqfHMRayzrxxOyQUyveeZ/RJLLqqBmjGy1kqgHq5T6vsnCVmn7iRsmNKeQ/sHtGDLyXNG@lists.postgresql.org X-Gm-Message-State: AOJu0YzlYTNhQ8fRwvLGcxf47uDdZ+q11Cm5tF748q2IOfAtcUjCLqXB cxNP1dHTUdSt92oTcRCWHFn+VNQ341ULQToGtXLnqzJY4KHbldqNa3AFG7b7W8xiLEMZIOWeb8A eQ3D3j43hdr6q6oGPCYK/jssM3tw= X-Gm-Gg: ASbGncsU4vSBjZD5zxl1EQ/kvZuNvqmeevi0HtvFEFhLyVJu8glnEFv6UY7Bh42PLas NihQKLHmIfRYu4Fmp0FtML1Ng0/LxABHsFb27zuSitvJ6KP3vYWmM2FItnuFzrVlcUvT06nikjx ZIml4MvG/P3jjjGSwSR2w+E26yS+FFVwarvYY= X-Google-Smtp-Source: AGHT+IFm/Gp/uKicQlF+2wxuYmLYEQB73pIGHOV6GHx5n+PHwgSehFFbsbNTqWDKCEQ7tIJcNr6LAKEXtuhhJgREnLc= X-Received: by 2002:a2e:9d12:0:b0:30c:514c:55d4 with SMTP id 38308e7fff4ca-30d7e228fb2mr41700911fa.16.1742870326486; Mon, 24 Mar 2025 19:38:46 -0700 (PDT) MIME-Version: 1.0 References: <1831838.1742656359@sss.pgh.pa.us> <80506.1742660683@sss.pgh.pa.us> <461405.1742691859@sss.pgh.pa.us> <1189112.1742869660@sss.pgh.pa.us> In-Reply-To: <1189112.1742869660@sss.pgh.pa.us> From: Sami Imseih Date: Mon, 24 Mar 2025 21:38:35 -0500 X-Gm-Features: AQ5f1JpTPvj3aSkLSwlTvy9qUYGv_V5Swk4Fz6CGi4oQYyQ9rsVz1EKh4XzYUsk Message-ID: Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX To: Tom Lane Cc: Michael Paquier , Christoph Berg , PostgreSQL Hackers , ma lz Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > select * from foo s1; > select * from foo s2; ah, thanks for pointing this out. Not as good of a workaround as a comment since one must change aliases, but at least there is a workaround... > As against this, there is probably also a set of people who would > *like* identical queries on identically-rowtyped tables in different > schemas to be merged. Right now they have no way to make that happen. I agree that some may want stats to merge for the same tables, and others may not. I will suggest this with some hesitation, but why not make this behavior configurable via a GUC? We recently introduced query_id_squash_values for controlling the merge of an IN list, maybe this is another queryId behavior we should provide a configuration for? -- Sami Imseih Amazon Web Services (AWS)