From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: REINDEX backend filtering |
Date: | 2020-12-14 07:45:08 |
Message-ID: | X9cYBC+COBQUfdQ6@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 03, 2020 at 05:31:43PM +0800, Julien Rouhaud wrote:
> Now that we have the infrastructure to track indexes that might be corrupted
> due to changes in collation libraries, I think it would be a good idea to offer
> an easy way for users to reindex all indexes that might be corrupted.
Yes. It would be a good thing.
> The filter is also implemented so that you could cumulate multiple filters, so
> it could be easy to add more filtering, for instance:
>
> REINDEX (COLLATION 'libc', COLLATION 'not_current') DATABASE mydb;
>
> to only rebuild indexes depending on outdated libc collations, or
>
> REINDEX (COLLATION 'libc', VERSION 'X.Y') DATABASE mydb;
>
> to only rebuild indexes depending on a specific version of libc.
Deciding on the grammar to use depends on the use cases we would like
to satisfy. From what I heard on this topic, the goal is to reduce
the amount of time necessary to reindex a system so as REINDEX only
works on indexes whose dependent collation versions are not known or
works on indexes in need of a collation refresh (like a reindexdb
--all --collation -j $jobs). What would be the benefit in having more
complexity with library-dependent settings while we could take care
of the use cases that matter the most with a simple grammar? Perhaps
"not_current" is not the best match as a keyword, we could just use
"collation" and handle that as a boolean. As long as we don't need
new operators in the grammar rules..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-12-14 07:48:05 | Re: pg_waldump error message fix |
Previous Message | Kyotaro Horiguchi | 2020-12-14 07:01:15 | Re: Asynchronous Append on postgres_fdw nodes. |