Re: pg_upgrade and statistics - Mailing list pgsql-hackers

From Greg Stark
Subject Re: pg_upgrade and statistics
Date
Msg-id CAM-w4HO4tmF16BApEotvFKViW4X0j=Et7sssZeKs+pnZwdU55w@mail.gmail.com
Whole thread Raw
In response to pg_upgrade and statistics  (Daniel Farina <daniel@heroku.com>)
Responses Re: pg_upgrade and statistics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: pg_upgrade and statistics  (Bruce Momjian <bruce@momjian.us>)
Re: pg_upgrade and statistics  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Mar 13, 2012 at 1:38 AM, Daniel Farina <daniel@heroku.com> wrote:
> You probably are going to ask: "why not just run ANALYZE and be done
> with it?"

Uhm yes. If analyze takes a long time then something is broken. It's
only reading a sample which should be pretty much a fixed number of
pages per table. It shouldn't take much longer on your large database
than on your smaller databases.

Perhaps you're running vacuum analyze by mistake?

If Analyze is taking a long time then we're getting the worst of both
worlds. The statistics are very poor for certain metrics (namely
ndistinct). The main reason we don't do better is because we don't
want to do a full scan.


-- 
greg


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: foreign key locks, 2nd attempt
Next
From: Robert Haas
Date:
Subject: Re: patch for parallel pg_dump