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 1tw9lQ-00BGgn-8z for pgsql-hackers@arkaria.postgresql.org; Sun, 23 Mar 2025 01:04:32 +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 1tw9lO-006CQs-HD for pgsql-hackers@arkaria.postgresql.org; Sun, 23 Mar 2025 01:04:30 +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 1tw9lO-006CNf-82 for pgsql-hackers@lists.postgresql.org; Sun, 23 Mar 2025 01:04:30 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tw9lM-000alg-08 for pgsql-hackers@lists.postgresql.org; Sun, 23 Mar 2025 01:04:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 52N14Jw3461406; Sat, 22 Mar 2025 21:04:19 -0400 From: Tom Lane To: Michael Paquier cc: Christoph Berg , PostgreSQL Hackers , ma lz Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX In-reply-to: References: <1831838.1742656359@sss.pgh.pa.us> <80506.1742660683@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Sun, 23 Mar 2025 09:47:31 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <461404.1742691859.1@sss.pgh.pa.us> Date: Sat, 22 Mar 2025 21:04:19 -0400 Message-ID: <461405.1742691859@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > Alias.aliasname is not qualified, so it means that we'd begin to > assign the same query ID even if using two relations from two schemas > depending on what search_path assigns, no? Right. I'm arguing that that's good. The proposed patch already obscures the difference between similar table names in different (temp) schemas, and I'm suggesting that taking that a bit further would be fine. Note that if the tables we're considering don't have identical rowtypes, the queries would likely jumble differently anyway due to differences in Vars' varattno and vartype. regards, tom lane