Re: Adding skip scan (including MDAM style range skip scan) to nbtree
От | Peter Geoghegan |
---|---|
Тема | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Дата | |
Msg-id | CAH2-WzknOSR9Eeov1Bvrcn1kFKoxDmXHmUMO0G7G5JYEOdLGBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Adding skip scan (including MDAM style range skip scan) to nbtree (Natalya Aksman <natalya@tigerdata.com>) |
Ответы |
Re: Adding skip scan (including MDAM style range skip scan) to nbtree
|
Список | pgsql-hackers |
On Wed, Sep 10, 2025 at 2:59 PM Natalya Aksman <natalya@tigerdata.com> wrote: > But after btrescan resets "so->numberOfKeys = 0", so->skipScan is not reset to "false" in _bt_preprocess_keys becauseof 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
В списке pgsql-hackers по дате отправления: