Re: REINDEX backend filtering

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