Tom Lane wrote:
> I wrote:
> > "Sergey E. Koposov" 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 ...
>
> Sure enough, that's the problem. pg_
"Sergey E. Koposov" writes:
> I wonder what should be the best way to proceed for already migrated
> databases -- running analyze repeatedly may not be the best way for
> very large clusters with large tables...
You can just manually update pg_class.reltuples to a more reasonable
value.
On Tue, 30 Aug 2011, Tom Lane wrote:
Sure enough, that's the problem. pg_upgrade leaves relpages/reltuples
set to zero, but it also imports the visibility map pages from the old
cluster. If the old visibility map shows the table as all-visible,
then this happens when you try to VACUUM ANALYZE
I wrote:
> "Sergey E. Koposov" 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 ...
Sure enough, that's the problem. pg_upgrade leaves relpages/reltuple
"Sergey E. Koposov" 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
Hello hackers,
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.
I have a set of *static* tables for which "explain select * " gives
row number estimates which are an order of magnitude lower than the actual
number of rows in a
