From: Nathan Bossart <nathandbossart@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
Date: Thu, 29 Jun 2023 13:56:38 -0700
Message-ID: <20230629205638.GA2054380@nathanxps13> (raw)
In-Reply-To: <20230629.141626.886053266048932185.horikyota.ntt@gmail.com>
References: <20230628232402.GA1954626@nathanxps13>
<20230629.141626.886053266048932185.horikyota.ntt@gmail.com>
Thanks for taking a look.
On Thu, Jun 29, 2023 at 02:16:26PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart <nathandbossart@gmail.com> wrote in
>> I debated also allowing users to specify different types of objects in the
>> same command (e.g., "vacuumdb --schema myschema --table mytable"), but it
>> looked like this would require a more substantial rewrite, and I didn't
>> feel that the behavior was intuitive. For the example I just gave, does
>> the user expect us to process both the "myschema" schema and the "mytable"
>> table, or does the user want us to process the "mytable" table in the
>> "myschema" schema? In vacuumdb, this is already blocked, but reindexdb
>
> I think spcyfying the two at once is inconsistent if we maintain the
> current behavior of those options.
>
> It seems to me that that change clearly modifies the functionality of
> the options. As a result, those options look like restriction
> filters. For example, "vacuumdb -s s1_* -t t1" will vacuum all table
> named "t1" in all schemas matches "s1_*".
Sorry, I'm not following. I intentionally avoided allowing combinations of
--schema and --table in the patches I sent. This is the current behavior
of vacuumdb. Are you suggesting that they should be treated as restriction
filters?
> While I think this is useful, primarily for system catalogs, I'm not
> entirely convinced about its practicality to user objects. It's
> difficult for me to imagine that a situation where all databases share
> the same schema would be major.
>
> Assuming this is used for user objects, it may be necessary to safely
> exclude databases that lack the specified schema or table, provided
> the object present in at least one other database. But the exclusion
> should be done with printing some warnings. It could also be
> necessary to safely move to the next object when reindex or cluster
> operation fails on a single object due to missing prerequisite
> situations. But I don't think we might want to add such complexity to
> these "script" tools.
Perhaps we could add something like a --skip-missing option.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, horikyota.ntt@gmail.com
Subject: Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
In-Reply-To: <20230629205638.GA2054380@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox