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 1sjWfU-001VB3-AR for pgsql-admin@arkaria.postgresql.org; Thu, 29 Aug 2024 04:21:56 +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 1sjWfS-00EOUf-DA for pgsql-admin@arkaria.postgresql.org; Thu, 29 Aug 2024 04:21:54 +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 1sjWfS-00EOU1-1z for pgsql-admin@lists.postgresql.org; Thu, 29 Aug 2024 04:21:54 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sjWfQ-001x9n-5p for pgsql-admin@postgresql.org; Thu, 29 Aug 2024 04:21:53 +0000 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5bef295a2b4so377633a12.0 for ; Wed, 28 Aug 2024 21:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724905309; x=1725510109; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=XOXnsbBiECFyJ7TxwyOpJQdapinIhoLBK3pawsnIwPc=; b=GUOzyBFKLKNLmaElNb6zhnUitPuyLoOlcgtczY0d9kQMwZOCGwGSJhyj/LBSoE2AIu n8LgfpJhv+Bl2/f3+zD8fymJ1GnaCvcKgIPt3o0sMkgFd1pTBMAJQrxeLvjmvbslrYrp 9R43Rc6gac8tL//6r16TVQk6S114G9y+gSNyBPAILFXmYotDCRAjPWL53K3kVdqaC00W gviqZBFu0JSWF/VRn0NCBg8F03bhRuo0eXabodo7y9V6Nhh3sjrw8GWKuSBE1hWrZsSz 7F/V1pXU65O1pr+myxiHJlhXEqYCd129tE7ffU/G5neo9Xzc3njy9js0nNT4tN0uV58t AQIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724905309; x=1725510109; h=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=XOXnsbBiECFyJ7TxwyOpJQdapinIhoLBK3pawsnIwPc=; b=tMsIpOGIji75c8Qk0B32aNOn/JwGM61dg2R4z7BT7j5zvFeEuT2GAcRhXN2YHZjr4E SL1JwEsdsmESM9ycVAZfGzh957N2PcnBLgmrLLeamt/LAGwcgR7vkxdrFZQBFUR1tEXA 4GmPxzKK0m9+hIVdkV+3NMsjKNiXFogjvQWjZyysrTFN1FFeBLNhz2KDEijlBqP4zy1D M6g3BwyiIEbfShs0ol+hfJsWUwenU9eBmt1SAmZgva+POPYjyjfTbZO4wnOOn8076KA5 4MQF+PyQsDkD0BsRlOuTaktJcJgivab/csbdj6kOO0E/DGxnnGKBGf7QwKMPJmW0bta4 rWDA== X-Gm-Message-State: AOJu0YzHODNg4N+XJt9WvsZMe3kftg/z4KvoVfV+jjDbeSquA5zGRIR2 1ng52odsghq0qJ30qHrC6vk2a5ADZ7o4Y/yTCb79nRC1bPsuyT1aOckbo/m/FgKnHdUfrECtRfB S4KGJBJARj1hjbv22YzPSCJdDG2szXQ== X-Google-Smtp-Source: AGHT+IHCZAjMxXasxfvsorLq3yFj1qHyXT4uIJJ7I3SPn1ljcSIuwfYdA42mGsPgSxoele6W8f+aJG8gbytTY7hMiFI= X-Received: by 2002:a05:6402:5186:b0:5be:e9f8:9ba4 with SMTP id 4fb4d7f45d1cf-5c2200ee1d9mr1292176a12.4.1724905308912; Wed, 28 Aug 2024 21:21:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wells Oliver Date: Wed, 28 Aug 2024 21:21:12 -0700 Message-ID: Subject: Re: pg_repack and table statistics To: pgsql-admin Content-Type: multipart/alternative; boundary="0000000000003581860620cad07a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003581860620cad07a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hmm, apologies, I'd delete this if I could, I was looking at stale data for pg_stat_user_tables, it indeed has a n_dead_tup of 0 after a repack. On Wed, Aug 28, 2024 at 9:16=E2=80=AFPM Wells Oliver wrote: > I find that the n_dead_tup value in pg_stat_user_tables is the same befor= e > and after a successful pg_repack of that table (ditto all the values > really). Is there something that should be done after a repack to have > those stats updated, or is their unchanging value a sign of repack failin= g > for some reason? > > -- > Wells Oliver > wells.oliver@gmail.com > --=20 Wells Oliver wells.oliver@gmail.com --0000000000003581860620cad07a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm= , apologies, I'd delete this if I could, I was looking at stale data fo= r pg_stat_user_tables, it indeed has a n_dead_tup of 0 after a repack.

On Wed, Aug 28, 2024 at 9:16=E2=80=AFPM Wells Oliver <wells.oliver@gmail.com> wrote:
I find that the=C2=A0n_dead_tu= p value in=C2=A0pg_stat_user_tables is the same before and after a successf= ul pg_repack of that table (ditto all the values really). Is there somethin= g that should be done after a repack to have those stats updated, or is the= ir unchanging value a sign of repack failing for some reason?
--


--
--0000000000003581860620cad07a--