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 1siNBN-003DDc-8d for pgsql-admin@arkaria.postgresql.org; Mon, 26 Aug 2024 00:02:05 +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 1siNBL-002PVM-A7 for pgsql-admin@arkaria.postgresql.org; Mon, 26 Aug 2024 00:02:03 +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.94.2) (envelope-from ) id 1siNBK-002PVE-Px for pgsql-admin@lists.postgresql.org; Mon, 26 Aug 2024 00:02:03 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1siNBI-001QnX-Jz for pgsql-admin@lists.postgresql.org; Mon, 26 Aug 2024 00:02:02 +0000 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3719753d365so2002194f8f.2 for ; Sun, 25 Aug 2024 17:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20230601.gappssmtp.com; s=20230601; t=1724630518; x=1725235318; 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=2ot2Z94gr5qC9HvUO4ZQ4oeyj/tUeOr9qWGftyRgESE=; b=BHJu3V+h2Vv/nO4UCPcu4aXZmyFx2CydNBffX3rVsLYZiu5E4Lt7SDhmHe6KAh95B6 OCY/ye9XXokEeDn25wqGl6UzfQ5MVvNF/DXv9TXOywX74ZwunT0W0qZ7HgEtIO29l5yz h1KN5ZaXLdWBTWTAfFIJC/KAv/JTuc/lq5LZXHcTKglwDIuUL8VCkBpXXnqxl3KZmZmb hlEa2oJbTgI8qm9fDpm4NCqBN1yb5nGyfPB7TDID/afxavQKQJNojwAg+FXMCqioQAXg J6tPYkadE2l0WtSEbART1+SJqSJl4q/YsfvxbA83OQ8byGpdQj8n1MBhJSEDxZIS8WLp IEyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724630518; x=1725235318; h=content-transfer-encoding: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=2ot2Z94gr5qC9HvUO4ZQ4oeyj/tUeOr9qWGftyRgESE=; b=Bv3UKZAbTf3Bj7fNzvpe4fnEb9jbB1ZG+ztNpwGd1cUtM1Gy//QClS7KaiOnP/ip8O jzhpvCoN+oKqrDLPfdnnr59YiJWWu+04bAfCAQhxwsI/eNiIOuEJ36MBYMr1vWOsb/Bh TX/hLDyrBzfZSFwt2cWPNq7md2c1I+1bOBXSxXY6GsfZ7IWTs7v8TZRaI6BKEE/6y3dD D2QyhJge7XTCJszrD5jPmsaDdMIfAukG0uC1yO1H1q9B+XWaWsZwV879alPWNfd27GE1 5QMyayBiKfBs8dAtPcrieo5BpPKi2D9voO5Q3mRcl49q7frRYix08bBHCykNsfRslYxb QEmg== X-Gm-Message-State: AOJu0YzLcA4mC0jBJN7RdUaZbVfXtpcsihpOivovQaV0s3NVRs+HvgK/ TSnqhENj74kOyKXiOTilYl/NjicKxvX/O2LV/2eAKCpPC/BjG6y/vKp26WJMCNhmUlOlgnb2LRP rxm4Vhunzn2Ybsrv0wKIFmZbZuq6YU+EK2IdAqQ== X-Google-Smtp-Source: AGHT+IFYutG4Em9EIhv99Waeb5A8Hpn6bSNjCiUY3c3ZNJcDNuSvQI91mdKjXZfh+l2qho8GxfB6+4Ts5uXKBKT3A8c= X-Received: by 2002:a5d:5849:0:b0:367:9769:35b0 with SMTP id ffacd0b85a97d-3731187e50bmr7031065f8f.4.1724630518224; Sun, 25 Aug 2024 17:01:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Geoghegan Date: Sun, 25 Aug 2024 20:01:32 -0400 Message-ID: Subject: Re: Is index deduplication active on an index To: Craig Milhiser Cc: pgsql-admin@lists.postgresql.org 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 Fri, Aug 23, 2024 at 3:25=E2=80=AFPM Craig Milhiser = wrote: > Is there a way I can determine if index deduplication is active on the in= dexes? > > I inherited a database that has been upgraded from v12 to 13 to 16. I che= cked the upgrade scripts used and there was not a reindex run during the up= grades. Someone may have run a reindex over the years. You can do this using contrib/pageinspect, which has a function that can read the index metapage for you. For example, the following query shows the 10 largest indexes that cannot use deduplication: create extension if not exists pageinspect; SELECT c.relname, c.relpages FROM pg_index i JOIN pg_opclass op ON i.indclass[0] =3D op.oid JOIN pg_class c ON i.indexrelid =3D c.oid JOIN pg_am am ON op.opcmethod =3D am.oid JOIN pg_namespace n ON c.relnamespace =3D n.oid WHERE am.amname =3D 'btree' AND NOT (select allequalimage AS supports_deduplication FROM bt_metap(n.nspname || '.' || c.relname)) AND c.relkind =3D 'i' AND i.indisready AND i.indisvalid ORDER BY c.relpages DESC LIMIT 10; Note, however, that this will show you indexes that don't use deduplication regardless of the underlying reason. It could just be a matter of running REINDEX to get deduplication working, but it might also be due to certain implementation level restrictions that you can't do anything about. For example, indexes on numeric columns don't support deduplication. The data types (opclasses, actually) that don't support deduplication are listed towards the end of this section of the docs: https://www.postgresql.org/docs/current/btree-implementation.html#BTREE-DED= UPLICATION --=20 Peter Geoghegan