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