Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
От | Nathan Bossart |
---|---|
Тема | Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases |
Дата | |
Msg-id | 20230629205638.GA2054380@nathanxps13 обсуждение исходный текст |
Ответ на | Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: