Committed, with your suggestions.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4 April 2014 16:01, Andres Freund and...@2ndquadrant.com wrote:
+ const char *stage_commands[] = {
+ SET default_statistics_target=1; SET
vacuum_cost_delay=0;,
+ SET default_statistics_target=10; RESET
vacuum_cost_delay;,
+
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
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
On 2014-01-14 22:22:08 -0500, Peter Eisentraut wrote:
+ listitem
+ para
+Only calculate statistics for use by the optimizer (no vacuum),
+like option--analyze-only/option. Run several stages of analyze
+with different configuration settings, to produce
Jeff Janes jeff.ja...@gmail.com wrote:
But I do wonder what experience people have with the 3 stage
process, how useful is it empirically? If you can't open the
database for general use until the 3rd phase is done, then you
would just jump to doing that stage, rather than working through
On Tue, Jan 21, 2014 at 9:06 AM, Oskari Saarenmaa o...@ohmu.fi wrote:
09.01.2014 05:15, Peter Eisentraut kirjoitti:
pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs
vacuumdb --analyze-only in three stages with different statistics target
settings to get a fresh cluster
09.01.2014 05:15, Peter Eisentraut kirjoitti:
pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs
vacuumdb --analyze-only in three stages with different statistics target
settings to get a fresh cluster analyzed faster. I think this behavior
is also useful for clusters or
On Thu, Jan 9, 2014 at 01:03:08PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I was referring to the analyze-in-stages logic, which is not specific
to 8.4. I don't see a reason not to put that into vacuumdb.
Right, that's Peter's core proposal, which I agreed with.
Bruce Momjian br...@momjian.us writes:
I assume pg_upgrade would just tell the user what vacuumdb command to
run, rather than create a script to call it. If they have to run two
commands, we will output the two commands.
Why would we change the operational procedure of run this script
after
On Fri, Jan 10, 2014 at 08:15:53PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assume pg_upgrade would just tell the user what vacuumdb command to
run, rather than create a script to call it. If they have to run two
commands, we will output the two commands.
Why
On Fri, 2014-01-10 at 20:21 -0500, Bruce Momjian wrote:
Bear in mind also that some may have scripted the call of the script
already, so you'd be breaking their scripts; to achieve what?
Uh, I didn't think enough people scripted pg_upgrade to be worth it.
I think pg_upgrade has so many
Bruce Momjian br...@momjian.us writes:
On Fri, Jan 10, 2014 at 08:15:53PM -0500, Tom Lane wrote:
Why would we change the operational procedure of run this script
after pg_upgrade? It just complicates life for users.
If it is one command, why use a script? Just give them the command.
On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs
vacuumdb --analyze-only in three stages with different statistics target
settings to get a fresh cluster analyzed
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think this vacuumdb feature should deal with any
version-conversion issues. So it sounds like the thing to do is keep the
wrapper script, which will give us a place to put any
On Thu, Jan 9, 2014 at 12:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think this vacuumdb feature should deal with any
version-conversion issues. So it sounds like the thing to
Robert Haas robertmh...@gmail.com writes:
I was referring to the analyze-in-stages logic, which is not specific
to 8.4. I don't see a reason not to put that into vacuumdb.
Right, that's Peter's core proposal, which I agreed with. The issue
was what to do with some other steps that pg_upgrade
Peter Eisentraut pete...@gmx.net writes:
pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs
vacuumdb --analyze-only in three stages with different statistics target
settings to get a fresh cluster analyzed faster. I think this behavior
is also useful for clusters or databases
18 matches
Mail list logo
