Re: amcheck support for BRIN indexes

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: amcheck support for BRIN indexes
Date: 2025-07-07 12:10:07
Message-ID: a5313e34-3fa2-4d66-ba88-e4df9ea3b4af@vondra.me
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/7/25 13:06, Arseniy Mukhin wrote:
> On Sun, Jul 6, 2025 at 10:49 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>>
>> On 2025-Jul-06, Arseniy Mukhin wrote:
>>
>>> Sorry, forget to run a full test run with the new patch version. Some
>>> tests were unhappy with the new unknown support function. Here the new
>>> version with the fix.
>>
>> Hello, I think this patch is probably a good idea. I don't think it
>> makes sense to introduce a bunch of code in 0003 only to rewrite it
>> completely in 0005. I would ask that you re-split your WITHIN_RANGE
>> (0004) to appear before the amcheck code, and then write the amcheck
>> code using that new functionality.
>
> Hi, Álvaro!
>
> Thank you for looking into this.
>
> OK, we can easily revert to the version with consistent function if
> needed, so let's get rid of it.
>

Alvaro, what's your opinion on the introduction of the new WITHIN_RANGE?
I'd probably try to do this using the regular consistent function:

(a) we don't need to add stuff to all BRIN opclasses to support this

(b) it gives us additional testing of the consistent function

(c) building a scan key for equality seems pretty trivial

What do you think?

--
Tomas Vondra

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-07-07 12:18:20 Re: Inconsistent LSN format in pg_waldump output
Previous Message Tomas Vondra 2025-07-07 12:01:53 Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach