Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gz0UR-0003yC-Aw for pgsql-performance@arkaria.postgresql.org; Wed, 27 Feb 2019 14:47:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gz0UP-0001ug-L4 for pgsql-performance@arkaria.postgresql.org; Wed, 27 Feb 2019 14:47:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gz0UP-0001uZ-DG for pgsql-performance@lists.postgresql.org; Wed, 27 Feb 2019 14:47:17 +0000 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gz0UN-0002pT-1x for pgsql-performance@postgresql.org; Wed, 27 Feb 2019 14:47:17 +0000 Received: by mail-io1-xd2d.google.com with SMTP id k21so13656177ior.13 for ; Wed, 27 Feb 2019 06:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance; bh=6hJm8fEKdy8hOrYpmpwKUnK+d1Du8ytZuwKVjtTJO/E=; b=V36h/3CubahZFzYp5QVel5GKqYLidQwfPCk0MA+ibHegX7FXLmyJmH9Qd2f4NOeNw2 psK+vIJ6Ru+Hvc6gLbBczfwdLdMr+3bPYoKvrgIiaf5lmWZhZ+tUsWdzoKYn7K0HkKtF zqZ0r7zv4ibiV0GpNSz++uNOHxJOhGknDV/EmRsfVQJywV/EU7yP/i2dRtkDeigLmqlc xI9miCWIbxZR4OPbAGmLHfVQYSVukWLcCeXquDi9FjFW0JNBT9QVddxaCYBUL48fT/m2 UI7q+GNNTaMQ7Q/nX9nIdc87yfPmXGJfty0NCVxvgxROzHEODEwuI+u27uo+kxgeC7N1 azcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=6hJm8fEKdy8hOrYpmpwKUnK+d1Du8ytZuwKVjtTJO/E=; b=E7qRWyzuLxR17SR9fNsY86Z3mMES1UhfYjFvWSUqVtUoL0Yda3kDelJce1ZT/Ns4Ka 7v7HpGulNX5EBYVNwfQ+KyiysmRpc34xeeu9qSMAgLtT43COMOn3mwLa8oGUiWC9buKK An48zCIWpcDSIoXFKe1FfSkAmyrltc4zT4jvOsVnbNCYkpLZesyzM69VcsbyzxURutVW T3as8SbuXqMvEnz9OFsfq+7CYUtz7TUesjI0Zic7MR1ZRi763w76kwsurXUbOFRcBt32 6dywQup0NSKns2eFuz3X9swjSeVBq/01EFbg1Pc41rJctM7HCG/Gjw7H9Ed/Ku8fHpSZ rb1Q== X-Gm-Message-State: APjAAAWeJWNFvzbe6oIwgAFGPyWdiXW+QYET1LisEkjplJQ4wM+ZamUr nG9sRyjrprTUuqspnPeNLOvXs06f X-Google-Smtp-Source: APXvYqwmWlGb7uw3KVPC2c2Evqap1VL10dwM1Vp6t1oU02lFXVnv0OmNbv2PwC6MNb06gJ4ZEh/GUQ== X-Received: by 2002:a6b:90e:: with SMTP id t14mr2115231ioi.19.1551278832935; Wed, 27 Feb 2019 06:47:12 -0800 (PST) Received: from ?IPv6:::ffff:172.25.138.67? ([165.215.94.3]) by smtp.gmail.com with ESMTPSA id f142sm1266372itc.15.2019.02.27.06.47.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 06:47:12 -0800 (PST) Message-ID: <5c76a2f0.1c69fb81.a4b54.6182@mx.google.com> MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" From: Fd Habash Subject: What is pg_stat_user_tables Showing NULL for last_autoanalyze & last_autovacuum Date: Wed, 27 Feb 2019 09:47:13 -0500 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_9B5E8976-6FD1-41D9-A888-2D3B74F39A99_" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --_9B5E8976-6FD1-41D9-A888-2D3B74F39A99_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I have been able to locate four google search results with the same inquiry= . What=E2=80=99ve been able to understand is =E2=80=A6 1. If auto-vaccum is working as expected, stats collector does not nullify = these values as part of a startup sequence or regular Maitenance. If a rela= tion gets auto[vacuumed|analyzed], the timestamps should remain.=20 2. A database engine crash or restart with =E2=80=98immediate=E2=80=99 opti= on will cause the timestamps to nullify.=20 3. Table never qualified for vacuuming based on auto-vacuum settings.=20 I can rule out all three scenarios above, but I still see null values. What= else could be at play here?=20 ---------------- Thank you --_9B5E8976-6FD1-41D9-A888-2D3B74F39A99_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I have been able to locate four google search results with the sam= e inquiry. What=E2=80=99ve been able to understand is =E2=80=A6

 

  1. If auto-vaccum is working as expected, stats collector does not = nullify these values as part of a startup sequence or regular Maitenance. I= f a relation gets auto[vacuumed|analyzed], the timestamps should remain.
  2. A database engine crash or restart with =E2=80=98immediate=E2=80=99 = option will cause the timestamps to nullify.
  3. Table never qualified= for vacuuming based on auto-vacuum settings.

 

I can rule out all three scenar= ios above, but I still see null values. What else could be at play here?

 

 = ;

 

-= ---------------
Thank you

 

<= /div>= --_9B5E8976-6FD1-41D9-A888-2D3B74F39A99_--