Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-01-09 17:37:48
Message-ID: CA+TgmoZ31rwBAymXHZqQcV5n52TsAsodfHA1PT_5DTE6bGiovA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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 freshly created by pg_restore
>> or any other loading mechanism, so it's suboptimal to have this
>> constrained to pg_upgrade.
>
>> Therefore, I suggest to add this functionality into the vacuumdb
>> program.
>
> Seems reasonable.
>
>> There are some details to be considered about who pg_upgrade would call
>> this. For example, would we keep creating the script and just have the
>> script call vacuumdb with the new option, or would we skip the script
>> altogether and just print a message from pg_upgrade? Also, pg_upgrade
>> contains logic to run a vacuum (not only analyze) in the final run when
>> upgrading from PostgreSQL <8.4 to deal with the freespace map. Not sure
>> how to adapt that; maybe just keep the script and run a non-analyze
>> vacuum after the analyze.
>
> 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 having to kluge up vacuumdb's behavior. That'll avoid breaking
> scripts that users might've built for using pg_upgrade, too.

I guess I don't see what's wrong with kludging up vacuumdb. It's not
like that's a very complicated utility; what will be hurt by a few
more options?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2014-01-09 17:44:18 Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Previous Message Robert Haas 2014-01-09 17:36:51 Re: Add CREATE support to event triggers