On 2023-10-29 12:45:08 -0400, [email protected] wrote: > On Sun, 29 Oct 2023 16:16:05 +0100 Peter J. Holzer wrote: > >However, the table statistics contain an estimate for the number of > >rows: > > > >hjp=> select schemaname, relname, n_live_tup from pg_stat_user_tables order > >by 3 desc; > >╔════════════╤═══════════════════════════╤════════════╗ > >║ schemaname │ relname │ n_live_tup ║ > >╟────────────┼───────────────────────────┼────────────╢ > >║ public │ ncvhis_2016_12_03 │ 9999977 ║ > >║ public │ random_test │ 1000000 ║ > >║ public │ beislindex │ 351 ║ > >║ public │ delivery │ 6 ║ > >... > > Are there prerequisites for this query? > Every (264) n_live_tup returned was zero... though, VERY fast.. :)
You need to ANALYZE the tables. Autovacuum should do this automatically
when it detects that a table has changed "enough" since the last
analyze, but for slowly growing tables that can sometimes take a long
time (indeed, I did an "analyze beislindex" just before the query above
because it showed only 25 tuples and I knew that wasn't right).
A count of 0 for a large table is weird, though.
Unless ... did you do a major version upgrade recently? That nukes the
statistics and you have to analyze everything again. Also, I'm not sure
if pg_restore triggers an analyze.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
