On Tue, Mar 13, 2012 at 3:30 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Mar 13, 2012 at 5:42 PM, Bruce Momjian <br...@momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers