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
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

In response to

Responses

Browse pgsql-hackers by date

  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