Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
Date
Msg-id 20230630.120517.1837918148802895337.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
List pgsql-hackers
At Thu, 29 Jun 2023 13:56:38 -0700, Nathan Bossart <nathandbossart@gmail.com> wrote in 
> 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?

No. I'm not suggesting. Just saying that they would look appear to
work as a restriction filters if those two options can be specified at
once.

> > 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.

But isn't it a bit too complicated for the gain?

I don't have a strong objection if we're fine with just allowing
"--all --schema=xxx", knowing that it will works cleanly only for
system catalogs.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Assert !bms_overlap(joinrel->relids, required_outer)
Next
From: Richard Guo
Date:
Subject: Re: Assert !bms_overlap(joinrel->relids, required_outer)