On Sun, Mar 14, 2021 at 10:57:37PM +0800, Julien Rouhaud wrote: > On Sun, Mar 14, 2021 at 08:54:11PM +0900, Michael Paquier wrote: >> In ReindexRelationConcurrently(), there is no filtering done for the >> index themselves. The operation is only done on the list of indexes >> fetched from the parent relation. Why? This means that a REINDEX >> (OUTDATED) INDEX would actually rebuild an index even if this index >> has no out-of-date collations, like a catalog. I think that's >> confusing. >> >> Same comment for the non-concurrent case, as of the code paths of >> reindex_index(). > > Yes, I'm not sure what we should do in that case. I thought I put a comment > about that but it apparently disappeared during some rewrite. > > Is there really a use case for reindexing a specific index and at the same > time > asking for possibly ignoring it? I think we should just forbid REINDEX > (OUTDATED) INDEX. What do you think?
I think that there would be cases to be able to handle that, say if a user wants to works on a specific set of indexes one-by-one. There is also the argument of inconsistency with the other commands. > I was thinking that users would be more interested in the list of indexes > being > processed rather than the full list of indexes and a mention of whether it was > processed or not. I can change that if you prefer. How invasive do you think it would be to add a note in the verbose output when indexes are skipped? > Did you mean index_has_outdated_collation() and > index_has_outdated_dependency()? It's just to keep things separated, mostly > for future improvements on that infrastructure. I can get rid of that > function > and put back the code in index_has_outadted_dependency() if that's overkill. Yes, sorry. I meant index_has_outdated_collation() and index_has_outdated_dependency(). -- Michael
signature.asc
Description: PGP signature
