Re: BTScanOpaqueData size slows down tests
От | Peter Geoghegan |
---|---|
Тема | Re: BTScanOpaqueData size slows down tests |
Дата | |
Msg-id | CAH2-WzkdXG0kBEuiH9ihXCPqjU14ZWHhCYJHeoOtdNp44yktew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BTScanOpaqueData size slows down tests (Álvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: BTScanOpaqueData size slows down tests
|
Список | pgsql-hackers |
On Wed, Apr 2, 2025 at 12:31 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote: > The mentioned commit (09cb5c0e7d6f) shows that we do partial memcpys, e.g. > > + memcpy(&so->markPos, &so->currPos, > + offsetof(BTScanPosData, items[1]) + > + so->currPos.lastItem * sizeof(BTScanPosItem)); > > That would obviously not work if this field weren't last. We still do > that, don't we? See btrestrpos(). Yes, we do -- but it's rare. It only happens in the case where we restore a mark after leaving the page where the mark was taken. In practice, merge joins tend to hardly ever do that (I know this because it makes testing annoyingly difficult). In other words, the optimization added by commit 08ae5edc5c seems to be very effective in practice. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: