| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Natalya Aksman <natalya(at)tigerdata(dot)com> |
| Cc: | 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-09-10 19:11:50 |
| Message-ID: | CAH2-WzknOSR9Eeov1Bvrcn1kFKoxDmXHmUMO0G7G5JYEOdLGBA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 10, 2025 at 2:59 PM Natalya Aksman <natalya(at)tigerdata(dot)com> wrote:
> But after btrescan resets "so->numberOfKeys = 0", so->skipScan is not reset to "false" in _bt_preprocess_keys because of this code: https://github.com/postgres/postgres/blob/9016fa7e3bcde8ae4c3d63c707143af147486a10/src/backend/access/nbtree/nbtpreprocesskeys.c#L1847
> After we set "so->numberOfKeys = 0" we quit on line 1847 before we get to the line 1874 where we do "so->skipScan = (numSkipArrayKeys > 0);" https://github.com/postgres/postgres/blob/9016fa7e3bcde8ae4c3d63c707143af147486a10/src/backend/access/nbtree/nbtpreprocesskeys.c#L1874
It sounds like the patch that I posted fixes the problem, without you
having to set so->skipScan externally (which sounds like a big
kludge). Can you confirm that it actually does fix the problem that
you're seeing?
TimescaleDB isn't following the letter of the law here. But I do still
see the argument for consistently setting so->skipScan during
preprocessing. That at least makes sense on general robustness
grounds.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2025-09-10 19:23:03 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Arseniy Mukhin | 2025-09-10 19:00:11 | Re: Proposal: Out-of-Order NOTIFY via GUC to Improve LISTEN/NOTIFY Throughput |