Hi,
On Wed, Aug 13, 2025 at 12:19 AM Arseniy Mukhin
<arseniy.mukhin.dev@gmail.com> wrote:
>
> I realized that solving the problem with opclasses without equality
> operator by letting user to define operator list has several
> drawbacks:
>
> It's not very convenient to call automatically? Because the calls are
> different from index to index. You can't just call
> brin_index_check('index', true, true) on everything. Maybe I'm wrong,
> but it seems like amcheck is a tool that is often used to periodically
> check the health of Postgres clusters (and there can be many of them),
> so users probably don't want to get into the details of each index.
>
> Also, it seems like we don't want the user to define the operator to
> check. We want them to pass in the "correct" operator if there is no
> equality operator. So there's no choice, we just want users to figure
> out what the correct operator is and pass it in. But we already know
> what the "correct" operator is. Maybe we should just implement an
> opclass <-> "correct" operator mapping on the database side? We also
> need opclass developers to be able to add such a mapping if they want
> their opclass to be supported by amcheck. Then during the check we can
> look up into the mapping and use the operators. I was thinking about a
> new catalog table or maybe adding it to BrinOpcInfo? Probably there is
> a better way to do it? If the mapping doesn't have an operator for
> opclass - no problem, we can skip the consistentFn call for such
> columns and maybe log a message about it. This way we don't have all
> these problems with operator list argument and with false positives
> when a user fails to realize what the "correct" operator is.
>
Is it something we need to think about? If we want to do something
about it, it looks like adding amcheck StrategyNumber to BrinOpcInfo
is the easiest option.
PFA the rebased version with several tiny fixes.
Best regards,
Arseniy Mukhin
