Re: Adding skip scan (including MDAM style range skip scan) to nbtree

On 8/29/25 10:38, Matthias van de Meent wrote:
> Hi,
>
> On Thu, 22 May 2025 at 19:57, Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
>>
>> On Tue, 20 May 2025, 22:14 Peter Geoghegan, <pg(at)bowt(dot)ie> wrote:
>>>
>>> On Mon, May 12, 2025 at 8:58 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>>>> I wonder if we can fix this problem by getting rid of the old support
>>>> routine #5, "options". It currently doesn't do anything, and I always
>>>> thought it was strange that it was added "for uniformity" with other
>>>> index AMs.
>>>
>>> Attached patch completely removes the nbtree "options" support
>>> function, while changing the support function number of skip support:
>>> it becomes support function #5 (the number previously used by
>>> "options"). This patch should fix the regression that Tomas complained
>>> about in an expedient way.
>>>
>>> It's likely that somebody else will run into the same problem in the
>>> future, the next time that a new support function is needed. But I
>>> think that it makes sense to do this much now -- we need a short term
>>> solution for Postgres 18.
>
> I just realized I hadn't checked in on this in a while, and I haven't
> seen Peter's patch get committed, nor my 0001. Do we consider this an
> Open Item and should this be improved in PG18, or is this something
> the user is expected to figure out and configure their systems for?
>
> If we want to fix it let's make a decision before RC1, so we don't
> have further breaking catalog changes between RC1 and 18.0.
>

The thing is that if we want to make this to RC1, it needs to go in
*today*. The RC1 is planned for next week, and there's a freeze starting
tomorrow.

> cc-ed RMT as this might be Open Item-worthy, and the patches up for
> debate both change catalog behaviour.
>

I agree with this, personally. Maybe the other RMT members will see it
differently, but it's probably to add an open item and then remove it
than miss an issue.

> Peter's patch at [0] changes opclass procedure numbers to reuse an
> existing but unused options regproc number.
> My 0001 at [1] changes the memory residence status of index access
> methods' handler_function output to const static, from dynamic in
> memctx.
>

IIRC both approaches address the issue. I'd go with Peter's patch for
18. The other patch is much more invasive / bigger, and we're right
before RC1 freeze. Maybe it's a good idea, but I'd say it's for 19.

Peter, any thoughts on this. Do you think it's reasonable / feasible to
push the fix?

regards

--
Tomas Vondra