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 1s7g6X-006nBu-89 for pgsql-bugs@arkaria.postgresql.org; Thu, 16 May 2024 18:45:26 +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 1s7g6W-00DJYm-NJ for pgsql-bugs@arkaria.postgresql.org; Thu, 16 May 2024 18:45:24 +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 1s7g6W-00DJYe-Eu for pgsql-bugs@lists.postgresql.org; Thu, 16 May 2024 18:45:24 +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.94.2) (envelope-from ) id 1s7g6T-000aCM-28 for pgsql-bugs@lists.postgresql.org; Thu, 16 May 2024 18:45:23 +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 44GIjIZC2135833; Thu, 16 May 2024 14:45:18 -0400 From: Tom Lane To: Tender Wang cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Tomas Vondra Subject: Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics In-reply-to: References: <18468-f5add190e3fa5902@postgresql.org> Comments: In-reply-to Tender Wang message dated "Thu, 16 May 2024 16:38:19 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2135831.1715885118.1@sss.pgh.pa.us> Date: Thu, 16 May 2024 14:45:18 -0400 Message-ID: <2135832.1715885118@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tender Wang writes: > generateClonedExtStatsStmt just copy t0's ext_stat info to t1. So this is a complete mess. The fundamental problem is that transformTableLikeClause believes it can process LIKE_STATISTICS requests immediately, because: * We may copy extended statistics if requested, since the representation * of CreateStatsStmt doesn't depend on column numbers. That was true apparently in the original, limited implementation where we only supported CREATE STATISTICS on plain columns. It's completely wrong for statistics on expressions. IMO what we need to do is make LIKE_STATISTICS work more like LIKE_INDEXES: postpone the transformation until expandTableLikeClause when we know the mapping from source columns to destination columns, and have a chance at converting the expression trees properly, comparably to generateClonedIndexStmt. > Right now, there is nothing to do in transformExtendedStatistics. > Can we update the varattno to the right value here? We don't know the column mapping there, either. What we need to have our hands on is the "attmap" computed in expandTableLikeClause, and then we can pass the stats expressions through map_variable_attnos(). I think this might not need to be a really large patch, but it definitely has to change where generateClonedExtStatsStmt is called from. I can have a go at it if Tomas doesn't want to. regards, tom lane