Re: amcheck support for BRIN indexes - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: amcheck support for BRIN indexes
Date
Msg-id a5313e34-3fa2-4d66-ba88-e4df9ea3b4af@vondra.me
Whole thread Raw
In response to Re: amcheck support for BRIN indexes  (Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>)
Responses Re: amcheck support for BRIN indexes
List pgsql-hackers

On 7/7/25 13:06, Arseniy Mukhin wrote:
> On Sun, Jul 6, 2025 at 10:49 PM Álvaro Herrera <alvherre@kurilemu.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




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach
Next
From: Álvaro Herrera
Date:
Subject: Re: Inconsistent LSN format in pg_waldump output