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-Wzm5jSpdh+E1Yhp=L8N04_rrOQvwk8AD_=fTgaHvRFf=yg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Adding skip scan (including MDAM style range skip scan) to nbtree (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Adding skip scan (including MDAM style range skip scan) to nbtree
|
Список | pgsql-hackers |
On Fri, May 9, 2025 at 9:33 AM Peter Geoghegan <pg@bowt.ie> wrote: > Can you try it again, with prepared statements? Alternatively, you > could selectively revert the changes that commit 92fe23d93aa made to > utils/adt/selfuncs.c, and then retest. Oh, wait, you already did try it with prepared statements. I'm rather puzzled as to why this happens, then. I expect that nbtree preprocessing will be able to use its usual single index column/index key fast path here -- the "We can short-circuit most of the work if there's just one key" path in _bt_preprocess_keys (and I expect that _bt_num_array_keys() quickly determines that no skip arrays should be added, preventing array preprocessing from ever really starting). As far as I'm aware, none of the skip scan commits introduced new palloc() overhead that would affect simple index scans like this. In general that should only happen with index scans of a multicolumn index that has at least one prefix column with no "=" condition. Most individual index scans (including index scans that just use inequalities) don't look like that. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: