Re: amcheck support for BRIN indexes
От | Tomas Vondra |
---|---|
Тема | Re: amcheck support for BRIN indexes |
Дата | |
Msg-id | a5313e34-3fa2-4d66-ba88-e4df9ea3b4af@vondra.me обсуждение исходный текст |
Ответ на | Re: amcheck support for BRIN indexes (Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>) |
Ответы |
Re: amcheck support for BRIN indexes
|
Список | 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 по дате отправления: