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-Wz=SABjX0AEedf7Md2aXKi0KkVVdKSTDozrpsF3Z0WV2ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Adding skip scan (including MDAM style range skip scan) to nbtree (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Adding skip scan (including MDAM style range skip scan) to nbtree
|
Список | pgsql-hackers |
On Fri, May 9, 2025 at 8:58 AM Tomas Vondra <tomas@vondra.me> wrote: > My conclusion from this is that 92fe23d93aa ends up doing a lot of > malloc calls, and this is what makes causes the regression. Otherwise > setting the MALLOC_TOP_PAD_ would not help like this. But I haven't > looked at the code, and I wouldn't have guessed the query to have > anything to do with skip scan ... While it's just about plausible that added nbtree preprocessing allocation overhead could account for this, I don't think it's actually possible here, since, as you said, this particular query simply isn't eligible to use a skip scan. It's impossible for any single column index to do so. The best guess I have is that the skip scan commit inadvertently added planner cycles, even though this query isn't eligible to use skip scan -- I thought that I'd avoided that, but perhaps I overlooked some subtlety. 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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: