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 Sun, Apr 13, 2014 at 10:49 AM, Tom Lane wrote:
> Simon Riggs 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 interna
Simon Riggs 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 t
On 4 April 2014 16:01, Andres Freund wrote:
>> + const char *stage_commands[] = {
>> + "SET default_statistics_target=1; SET
>> vacuum_cost_delay=0;",
>> + "SET default_statistics_target=10; RESET
>> vacuum_cost_delay;",
>> +
On 2014-01-14 22:22:08 -0500, Peter Eisentraut wrote:
> +
> +
> +Only calculate statistics for use by the optimizer (no vacuum),
> +like --analyze-only. Run several stages of analyze
> +with different configuration settings, to produce usable statistics
> +
Jeff Janes 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
> all 3 of them. If
On Tue, Jan 21, 2014 at 9:06 AM, Oskari Saarenmaa 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 analyzed
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 database
Bruce Momjian 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.
Because it won
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 man
On Fri, Jan 10, 2014 at 08:15:53PM -0500, Tom Lane wrote:
> Bruce Momjian 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 cha
Bruce Momjian 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 pg_upgrade"?
On Thu, Jan 9, 2014 at 01:03:08PM -0500, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 sometimes sticks
int
On Thu, Jan 9, 2014 at 12:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane 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 giv
Robert Haas writes:
> On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane 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 such special actions
>> without
On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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 freshly crea
18 matches
Mail list logo
