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 1tmdbR-008KeR-5I for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Feb 2025 18:54:53 +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 1tmdbP-006TP0-Ce for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Feb 2025 18:54: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 1tmdbP-006TOs-2u for pgsql-hackers@lists.postgresql.org; Mon, 24 Feb 2025 18:54:51 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tmdbM-000aIS-0m for pgsql-hackers@lists.postgresql.org; Mon, 24 Feb 2025 18:54:50 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-2211acda7f6so106914525ad.3 for ; Mon, 24 Feb 2025 10:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1740423286; x=1741028086; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=dxY4Tj4eOI0E8ADERFucw8VACBq0kiZ4HaTNKjqbBiE=; b=YlVH43KbthevUuQJXI6dcrPsM7ldrQGbyvjNZtjj3BqsfGyzj2oS5FNDCBWbCmspkE vX9C2BDWXGH2HMJx9k1sLVbZlYXJH19KDB4w4J0jO5cp0XZaYwFZJX0bF0M2ZqrGc1dX hJG3hsaMaxMSnmtNWTLM/M98kWqsZ3Qbf1RmksFUtvLFJN22F99kf4WbvAtRzrWEe7j7 wy1nZXAVAbfd5tEsrLlF8diNVyRISSuaCtixUfsPTeOrAtyLcDIsXThkTdWad8pE2gIX eQxGsSAJ9FPFKXm7m2ShMYHreal1W5eTHBCY6+ZQ2t3cehZK/rzNF0VJ4JRRBd+vILP1 Bo1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740423286; x=1741028086; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dxY4Tj4eOI0E8ADERFucw8VACBq0kiZ4HaTNKjqbBiE=; b=R6Lj8Quwj8s04DzJXfcqrtKSoUzwjrqQyGCbnsXvGpR3mB59UTP6U/Yvqup/BUceBX IhSj4xrUZdvparCsMcsVmkuquHqFMTu5YTcN+PKA0pm9Vr9u/WI+n6L7GIf+KLSAY9Cj 99txIrno4Jl8lU1WDbPmMYN2TYREKRQFKVX/eFdK1RZgdWc+gal6hL+5xK8JR2xvqyFE daV3mRR6VUkiMQFzlZF3E7hVXPfz+pl3mCa9joIkPqhoI/njM733fOMD2gQH9pSwlPJM 6KI5qESRt1wgHPC2FcAMPS998kF36Mpt5qtL1g8ub9JuM60aZ6ODC3BGCDtXoSRZTXDw oAWg== X-Forwarded-Encrypted: i=1; AJvYcCXJhlcY36qBw6A7S76daUIbFvht1oDLMur6bEbJgS1Flu0kISw3QEAVGrweqwdRkOR3+LvW6AZiguxLPIZY@lists.postgresql.org X-Gm-Message-State: AOJu0YzNeUiJiYEpSjOC0R11h46DYUzWYGEBPBlR+PvMhL/HP5xFkR7j ibFV3RdKhRlMAD3L+hmqTwvvCaju4SLr6N3B9SslPswee/TCuW6FIKVudDrFKQ== X-Gm-Gg: ASbGncsjeU+ntKr9iHPExaXIfMKC0qWzfhknfoOWvb16blr244VDX0+5qnJ2EbmR+nB +pOzXvb1anj7Tj+WS1W9s21P8RYSF4ozK+c1tIWUemOkfA/R9Ho1vXhm3K9+1k9WqAvKBAvPYTf ypazWZo4CAPVhGZcYuZ0yFGi99ftdDZCFYx8f6b7+z7L38ZDdOdEYCtVFEUY4mIJL2gjIdwj4ll 2g4pOETo9EaUnH52ke5rKghZqeNrNEJD5hQWgQ7qYox37q+pBH1ivaV4i7k2bIXXPNuJwQpG98k c3jEEwMTiLdCpJqv1FVxUyHsxU/AIWVHFJFarB++ufenIB8L11PA00VK+jVcuDLULwMY X-Google-Smtp-Source: AGHT+IGN7gtrm3Xft5VcsxV4+U13+S0xBVlB+ePqiNq6Fkf69TmnniP8dCRxRRUsD6IEiw3Z0ruyLw== X-Received: by 2002:a05:6a00:2e08:b0:730:76a1:3935 with SMTP id d2e1a72fcca58-73426ca8308mr22216809b3a.6.1740423285016; Mon, 24 Feb 2025 10:54:45 -0800 (PST) Received: from jeff-laptop.lan (c-76-102-242-158.hsd1.ca.comcast.net. [76.102.242.158]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7324273ca16sm21160738b3a.119.2025.02.24.10.54.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2025 10:54:44 -0800 (PST) Message-ID: <6d1c72b06fe3645a50897381d71ff1b39085abf6.camel@j-davis.com> Subject: Re: Statistics Import and Export From: Jeff Davis To: Corey Huinker , Tom Lane Cc: Andres Freund , Michael Paquier , jian he , Nathan Bossart , Bruce Momjian , Matthias van de Meent , Magnus Hagander , Stephen Frost , Ashutosh Bapat , Peter Smith , PostgreSQL Hackers , alvherre@alvh.no-ip.org Date: Mon, 24 Feb 2025 10:54:43 -0800 In-Reply-To: References: <3670503.1740173078@sss.pgh.pa.us> <3728741.1740178078@sss.pgh.pa.us> <97b451228227c555be1a4f79c4a62ddec9a74f06.camel@j-davis.com> <1457469.1740419458@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2025-02-24 at 13:47 -0500, Corey Huinker wrote: > There doesn't seem to be any way around it, but it will > slightly=C2=A0complicate the dump-ing side of things, in that we need to > either: >=20 > a) switch to attnums=C2=A0for index expressions and keep attname calls fo= r > everything else. The only stats for indexes are on expression columns, so AFAICT there's no difference between the above description and "use attnums for indexes and attnames for tables". Either way, I agree that's the way to go. We certainly want attnames for tables to keep it working reasonably well for cases where the user might be doing something more interesting than a binary upgrade, as you point out. But attribute numbers for indexes seem much more reliable: an index with a different attribute order is a fundamentally different index. Regards, Jeff Davis