From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: strange row number estimates in pg9.1rc1 |
Date: | 2011-08-30 05:34:38 |
Message-ID: | 8234.1314682478@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
> I'm seeing something weird which looks like a bug in 9.1rc1 after the
> upgrade 8.4->9.0->9.1 done using pg_upgrade.
Hm, I wonder what pg_upgrade left relpages/reltuples set to ...
> INFO: "lassource": found 0 removable, 0 nonremovable row versions in 0
> out of 6451184 pages
VACUUM is deciding that the table is all-visible and it need not scan
any of it ...
> INFO: "lassource": scanned 30000 of 6451184 pages, containing 270000 live
> rows and 0 dead rows; 30000 rows in sample, 806239 estimated total rows
... and then ANALYZE is scanning only 30000 of 6451184 pages, so even
though it knows the correct tuple density in those pages, it's not
licensed to change the reltuples total very much. If reltuples is way
off base to start with, then it will take a lot of ANALYZE cycles to
converge on a saner value. However, this doesn't leave us much closer
to understanding why it's off base to start with.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ding Yuan | 2011-08-30 07:15:19 | BUG #6184: Inconsistencies in log messages |
Previous Message | Tom Lane | 2011-08-30 04:59:01 | Re: spinlocks on HP-UX |