Re: strange row number estimates in pg9.1rc1

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

In response to

Responses

Browse pgsql-hackers by date

  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