Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb
Date
Msg-id 23627.1397400591@sss.pgh.pa.us
Whole thread Raw
In response to Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: PostgreSQL in Windows console and Ctrl-C
Next
From: Thomas Mayer
Date:
Subject: Re: Window function optimisation, allow pushdowns of items matching PARTITION BY clauses