| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
| Date: | 2025-05-09 14:22:57 |
| Message-ID: | CAH2-WzmdOETpceTr3wsTTTpu8jvNkYitw86uaGmiRZxJpL=p0A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 9, 2025 at 9:59 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I don't actually think that this kind of scan would have been affected
> by those known regressions -- since they don't use array keys. But it
> is definitely true that the queries that you're looking at very much
> rely on the optimization from commit 8a510275 (or its predecessor
> optimization, the "pstate.prechecked" optimization). As I said, my
> performance validation didn't target individual commits.
Wait, that's not it, either. Since the index scan that you use won't
find any matching tuples at all. It should land on the leftmost leaf
page, find that there are no tuples "WHERE bid = 0", ending the scan
before it ever really began.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stepan Neretin | 2025-05-09 14:39:02 | Re: [PATCH] avoid double scanning in function byteain |
| Previous Message | Tomas Vondra | 2025-05-09 14:22:44 | Re: Amcheck verification of GiST and GIN |