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

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, rmt(at)lists(dot)postgresql(dot)org, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Date: 2025-08-29 23:07:28
Message-ID: c562dc2a-6e36-46f3-a5ea-cd42eebd7118@vondra.me
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/29/25 21:03, Peter Geoghegan wrote:
> On Fri, Aug 29, 2025 at 9:10 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>> Peter, any thoughts on this. Do you think it's reasonable / feasible to
>> push the fix?
>
> I don't feel comfortable pushing that fix today.
>

Understood.

> Honestly, I'm still not sure what to do. My proposal was to just
> remove the totally unused options support function, which is probably
> fine. But since I don't really know why Alexander ever added the
> "options" support function in the first place (I don't even see a
> theoretical benefit), I'm not quite prepared to say that I know that
> it's okay to remove it now.
>

Right. I think removing the "options" is the only feasible solution for
PG18 at this point. Either that or nothing. The other patch is far too
invasive.

As for why the support procedure was added to existing index AMs, I
don't know. I suppose it as mostly for consistency, so that custom
oclasses could opclasses could use that. I have no idea if there are
plausible custom opclasses using this.

I'm not sure how I feel about removing the support proc. It feels pretty
arbitrary and fragile, and IIRC it doesn't even address the perf issue
(add a couple partitions and it'll hit the same issue). It just restores
the "threshold" to where it was for PG17. And it's fragile, because we
have no protections about hitting this glibc-specific behavior again. It
takes one new flag added somewhere, and we'll not even notice it.

So after thinking about this a bit more, and refreshing the context, I
think the right solution for PG18 is to do nothing.

regards

--
Tomas Vondra

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexandra Wang 2025-08-30 00:53:06 Re: SQL:2023 JSON simplified accessor support
Previous Message Melanie Plageman 2025-08-29 22:46:37 Incorrect logic in XLogNeedsFlush()