Re: pg_upgrade and statistics

On Tue, Mar 13, 2012 at 3:30 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Mar 13, 2012 at 5:42 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> What is the target=10 duration?  I think 10 is as low as we can
>> acceptably recommend.  Should we recommend they run vacuumdb twice, once
>> with default_statistics_target = 4, and another with the default?
>
> I'm not sure why we're so glibly rejecting Dan's original proposal.
....
> Dan's idea actually fixes the problem.

I appreciate your support, but I don't feel dismissed; I see the
obvious appeal of not having to port the catalog if a fast/good enough
regeneration technique can be found, so I'm glad people are trying
those out and measuring things. I think the main problem that is hard
to work around lies in our inability to trigger autoanalyze one-shot.

I can't really speak on the behalf of a smaller operation (where
pg_upgrade taking on the task of hacking catalogs is clearly very
desirable -- worth serious consideration), but for the scale of our
operation having to do our own catalog hacking at the cost of
possible-terribleness that can result from a botched pg_statistic is
not hugely concerning. Rather, the more insurmountable and general
problem we keep encountering is how we can trigger throttled
maintenance on a special basis. It is definitely in my interest to --
some day -- be able to run VACUUM FULL and REINDEX (provided
incremental-self-defragmenting indexes don't get written first)
without any disastrous impact on the user at all, including when they
attempt to drop the table (in which we should yield the lock and let
it happen) or alter its column definition.

--
fdr