Re: Allowing REINDEX to have an optional name

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Subject: Re: Allowing REINDEX to have an optional name
Date: 2022-06-02 00:02:33
Message-ID: Ypf+GU4zhvRTirJ1@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-06-02 00:37:58 Re: pg_upgrade test writes to source directory
Previous Message Michael Paquier 2022-06-01 22:43:06 Re: Prevent writes on large objects in read-only transactions