From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, benoit <benoit(at)hopsandfork(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Subject: | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |
Date: | 2023-10-15 20:50:43 |
Message-ID: | CAH2-Wz=_FQ0AVgoF+UT7EzafVyd7kanQ0-82BesrpjUHPtjLvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 28, 2023 at 5:32 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Sun, Sep 17, 2023 at 4:47 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > Attached is v2, which makes all array key advancement take place using
> > the "next index tuple" approach (using binary searches to find array
> > keys using index tuple values).
>
> Attached is v3, which fixes bitrot caused by today's bugfix commit 714780dc.
Attached is v4, which applies cleanly on top of HEAD. This was needed
due to Alexandar Korotkov's commit e0b1ee17, "Skip checking of scan
keys required for directional scan in B-tree".
Unfortunately I have more or less dealt with the conflicts on HEAD by
disabling the optimization from that commit, for the time being. The
commit in question is rather poorly documented, and it's not
immediately clear how to integrate it with my work. I just want to
make sure that there's a testable patch available.
--
Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Enhance-nbtree-ScalarArrayOp-execution.patch | application/octet-stream | 103.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-10-15 20:54:25 | Re: Optimizing "boundary cases" during backward scan B-Tree index descents |
Previous Message | Tom Lane | 2023-10-15 19:59:56 | Re: Can concurrent create index concurrently block each other? |