Re: Allowing REINDEX to have an optional name
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Bernd Helmle <mailings@oopsware.de>, Simon Riggs <simon.riggs@enterprisedb.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Date: 2022-06-02T00:02:33Z
Lists: pgsql-hackers
On Tue, May 31, 2022 at 02:30:32PM +0200, Alvaro Herrera wrote: > I was thinking the opposite: REINDEX DATABASE with or without a database > name should always process the user relations and skip system catalogs. > If the user wants to do both, then they can use REINDEX SYSTEM in > addition. > > The reason for doing it like this is that there is no way to process > only user tables and skip catalogs. So this is better for > composability. No objections from me to keep this distinction at the end, as long as the the database name in the command has no impact on the chosen behavior. Could there be a point in having a REINDEX ALL though that would process both the user relations and the catalogs, doing the same thing as REINDEX DATABASE today? By the way, the patch had better avoid putting a global REINDEX command that would process everything. As far as I recall, we've avoided such things on purpose because they are expensive, keeping around only cases that generate errors or skip all the relations. So having that in a TAP test would be better, I assume, for isolation. -- Michael
Commits
-
Tweak a bit the new TAP tests of REINDEX DATABASE/SYSTEM
- 2b99ce10c2bc 16.0 landed
-
Rework logic and simplify syntax of REINDEX DATABASE/SYSTEM
- 2cbc3c17a5c1 16.0 landed
-
Add more tests for REINDEX DATABASE/SYSTEM with relfilenode changes
- 5fb5b6c4c176 16.0 landed