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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-03-13 21:06:46 | Re: Command Triggers, patch v11 |
Previous Message | Bruce Momjian | 2012-03-13 20:17:27 | Re: pg_upgrade and statistics |