On Sun, Apr 13, 2014 at 10:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@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