Re: pg_upgrade and statistics - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade and statistics
Date
Msg-id 20120313193019.GD23967@momjian.us
Whole thread Raw
In response to Re: pg_upgrade and statistics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: pg_upgrade and statistics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: pg_upgrade and statistics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: pg_upgrade and statistics  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Tue, Mar 13, 2012 at 02:07:14PM -0500, Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
> > On Tue, Mar 13, 2012 at 01:18:58PM -0500, Kevin Grittner wrote:
>  
> >> 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?
>  
> cir=# select pg_size_pretty(pg_database_size('cir'));
>  pg_size_pretty 
> ----------------
>  2563 GB
> (1 row)
>  
> In case you meant "How large is that table that took 2.5 minutes to
> analyze?":
>  
> cir=# select pg_size_pretty(pg_total_relation_size('"CaseHist"'));
>  pg_size_pretty 
> ----------------
>  44 GB
> (1 row)
>  
> I've started a database analyze, to see how long that takes.  Even
> if each table took 1/4 second (like on the small database) with over
> 500 user tables, plus the system tables, it'd be 15 minutes.  I'm
> guessing it'll run over an hour, but I haven't timed it lately, so
> -- we'll see.

OK, so a single 44GB tables took 2.5 minutes to analyze;  that is not
good.  It would require 11 such tables to reach 500GB (0.5 TB), and
would take 27 minutes.  The report I had was twice as long, but still in
the ballpark of "too long".  :-(

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Potential reference miscounts and segfaults in plpython.c
Next
From: Peter Eisentraut
Date:
Subject: Re: about EncodeDateTime() arguments