Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade and statistics

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Daniel Farina" <daniel(at)heroku(dot)com>,"Greg Stark" <stark(at)mit(dot)edu>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-13 19:48:37
Message-ID: 4F5F5E450200002500046254@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
 
>>>> cir=# analyze "CaseHist";
>>>> ANALYZE
>>>> Time: 143450.467 ms
 
> 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".  :-(
 
We have a sister machine to the one used for that benchmark -- same
hardware and database.  The cost limit didn't seem to make much
difference:
 
cir=# set vacuum_cost_delay = 0;
SET
cir=# \timing on         
Timing is on.
cir=# analyze "CaseHist" ;
ANALYZE
Time: 146169.728 ms
 
So it really does seem to take that long.
 
-Kevin

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-03-13 19:52:45
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous:From: Robert HaasDate: 2012-03-13 19:48:32
Subject: Re: wal_buffers, redux

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group