Re: Allowing REINDEX to have an optional name

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: 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-05-31 09:04:58
Message-ID: 99c49d7a46902e20d57f92f7520e824e8929bc6c.camel@oopsware.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Am Dienstag, dem 10.05.2022 um 15:00 +0100 schrieb Simon Riggs:

[...]

>
> > I think REINDEX DATABASE reindexing the current database is a good
> > usability improvement in itself. But skipping the shared catalogs
> > needs an explicity syntax. Not sure how feasible it is but
> > something
> > like REINDEX DATABASE skip SHARED/SYSTEM.
>
> There are two commands:
>
> REINDEX DATABASE does every except system catalogs
> REINDEX SYSTEM does system catalogs only
>
> So taken together, the two commands seem intuitive to me.
>
> It is designed like this because it is dangerous to REINDEX the
> system
> catalogs because of potential deadlocks, so we want a way to avoid
> that problem.
>
> Perhaps I can improve the docs more, will look.
>

And we already have a situation where this already happens with REINDEX
DATABASE: if you use CONCURRENTLY, it skips system catalogs already and
prints a warning. In both cases there are good technical reasons to
skip catalog indexes and to change the workflow to use separate
commands.

Bernd

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2022-05-31 09:11:20 Re: Remove useless tests about TRUNCATE on foreign table
Previous Message Amit Kapila 2022-05-31 08:52:41 Re: Perform streaming logical transactions by background workers and parallel apply