Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb
Date: 2014-04-13 14:49:51
Message-ID: 23627.1397400591@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Mayer 2014-04-13 14:50:24 Re: Window function optimisation, allow pushdowns of items matching PARTITION BY clauses
Previous Message Andrew Dunstan 2014-04-13 13:23:44 Re: pgsql: Add ANALYZE into regression tests