Re: pg_upgrade and statistics

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade and statistics
Дата
Msg-id 20120313185326.GB23967@momjian.us
обсуждение исходный текст
Ответ на Re: pg_upgrade and statistics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: pg_upgrade and statistics
Список pgsql-hackers
On Tue, Mar 13, 2012 at 01:18:58PM -0500, Kevin Grittner wrote:
> Greg Stark <stark@mit.edu> wrote:
> > 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.
>  
> On a small database:
>  
> cc=# analyze "CaseHist";
> ANALYZE
> Time: 255.107 ms
> cc=# select relpages, reltuples from pg_class where relname =
> 'CaseHist';
>  relpages | reltuples 
> ----------+-----------
>      1264 |     94426
> (1 row)
>  
> Same table on a much larger database (and much more powerful
> hardware):
>  
> cir=# analyze "CaseHist";
> ANALYZE
> Time: 143450.467 ms
> cir=# select relpages, reltuples from pg_class where relname =
> 'CaseHist';
>  relpages |  reltuples  
> ----------+-------------
>   3588659 | 2.12391e+08
> (1 row)
>  
> Either way, there are about 500 tables in the database.

That is 2.5 minutes.  How large is that database?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade and statistics
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: LIST OWNED BY...