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-Wzk0AduEKWBnPVWr2v2+RZ4ZB0Sbm7iMwJBhTX=BAjVAEw@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 10:57 AM Tomas Vondra <tomas@vondra.me> wrote: > I see the regression even with variants that actually match some rows. > For example if I do this: > so that the query matches 100 rows, I get the same behavior. That's really weird, since the index scans will no longer be cheap. And yet whatever the overhead is still seems to be plainly visible. I would expect whatever the underlying problem is to be completely drowned out once the index scan had to do real work. I wonder if it could be due to the fact that I added a new support function, support function #6/skip support? That would have increased the size of things like RelationData.rd_support and RelationData.rd_supportinfo. Note that "sizeof(FmgrInfo)" is 48 bytes. Prior to skip scan, RelationData.rd_supportinfo would have required 48*5=240 bytes. After skip scan, it would have required 48*6=288 bytes. Maybe 256 bytes is some kind of critical threshold, someplace? -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: