From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Masahiro(dot)Ikeda(at)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com |
Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Date: | 2025-03-18 17:01:00 |
Message-ID: | CAEze2WjgrLPBt9YBCCYY1p=9TSjQgL5xoaeH3ob3gmekTD3XOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 17 Mar 2025 at 23:51, Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> On Tue, 11 Mar 2025 at 16:53, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> >
> > On Sat, Mar 8, 2025 at 11:43 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > > I plan on committing this one soon. It's obviously pretty pointless to
> > > make the BTMaxItemSize operate off of a page header, and not requiring
> > > it is more flexible.
> >
> > Committed. And committed a revised version of "Show index search count
> > in EXPLAIN ANALYZE" that addresses the issues with non-parallel-aware
> > index scan executor nodes that run from a parallel worker.
> >
> > Attached is v28. This is just to keep the patch series applying
> > cleanly -- no real changes here.
>
> You asked off-list for my review of 0003. I'd already reviewed 0001
> before that, so that review also included. I'll see if I can spend
> some time on the other patches too
My comments on 0004:
> _bt_skiparray_strat_decrement
> _bt_skiparray_strat_increment
In both functions the generated value isn't used when the in/decrement
overflows (and thus invalidates the qual), or when the opclass somehow
doesn't have a <= or >= operator, respectively.
For byval types that's not much of an issue, but for by-ref types
(such as uuid, or bigint on 32-bit systems) that's not great, as btree
explicitly allows no leaks for the in/decrement functions, and now we
use those functions and leak the values.
Additionally, the code is essentially duplicated between the
functions, with as only differences which sksup function to call;
which opstrategies to check, and where to retrieve/put the value. It's
only 2 instances total, but if you figure out how to make a nice
single function from the two that'd be appreciated, as it reduces
duplication and chances for divergence.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-03-18 17:26:14 | Re: making EXPLAIN extensible |
Previous Message | Jacob Champion | 2025-03-18 16:53:51 | Re: dblink: Add SCRAM pass-through authentication |