On Sun, Apr 13, 2014 at 10:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> ISTM that this is the way ANALYZE should work when run on a table that >> has never been analysed before. Let's just do this logic within >> ANALYZE and be done. > > Can't. Not unless you intend to make ANALYZE do internal commits > so that its output rows become visible to other transactions before > its done. (Which would be, shall we say, a damn bad idea.) > > Even without that implementation problem, I absolutely don't agree > that this is such a great thing that it should become not only the > default but the only obtainable behavior. It would slow down > ANALYZE, and would only be helpful if there is concurrent activity > that would benefit from the stats. There are plenty of scenarios > where that would be giving up something to get nothing.
Agreed. I suspect that's also true of the pg_upgrade behavior. Sure, there may be people for who the database will be immediately usable with a stats target of 1 or 10, but I bet there are also quite a few for whom it isn't, or who just wait for the whole thing to be done anyway before they fire the system up. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
