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

Re: pg_upgrade and statistics

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "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>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-13 20:29:22
Message-ID: 4F5F67D20200002500046266@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
 
> OK, good idea.  Kevin, can you test this:
> 
>   PGOPTIONS='-c default_statistics_target=10' vacuumdb --all
>     --analyze-only
> 
> Is it faster?  Thanks.
 
Well, I just did something similar in psql -- I disabled the delays
by:
 
set vacuum_cost_delay = 0;
 
I checked for any statistics overrides, and found none (if I did
this right):
 
cir=# select attrelid::regclass, attname, attstattarget from
pg_attribute where attstattarget > 0;
 attrelid | attname | attstattarget 
----------+---------+---------------
(0 rows)
 
I went even lower than you suggested:
 
set default_statistics_target = 4;
 
And it was much faster, but still more time than the pg_upgrade run
itself:
 
cir=# analyze;
ANALYZE
Time: 474319.826 ms
 
A little under 8 minutes.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2012-03-13 21:06:46
Subject: Re: Command Triggers, patch v11
Previous:From: Bruce MomjianDate: 2012-03-13 20:17:27
Subject: Re: pg_upgrade and statistics

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