Re: [PoC] Improve dead tuple storage for lazy vacuum
| От | John Naylor |
|---|---|
| Тема | Re: [PoC] Improve dead tuple storage for lazy vacuum |
| Дата | |
| Msg-id | CANWCAZYkjRd3ooO7u_NZGWUUWEtneLBWOpDQaKhrogXRExi0gw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PoC] Improve dead tuple storage for lazy vacuum (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: [PoC] Improve dead tuple storage for lazy vacuum
|
| Список | pgsql-hackers |
On Thu, Apr 25, 2024 at 8:36 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Mon, Apr 15, 2024 at 6:12 PM John Naylor <johncnaylorls@gmail.com> wrote: > > - RT_KEY_GET_SHIFT is not covered for key=0: > > > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L803 > > > > That should be fairly simple to add to the tests. > > There are two paths to call RT_KEY_GET_SHIFT(): > > 1. RT_SET() -> RT_KEY_GET_SHIFT() > 2. RT_SET() -> RT_EXTEND_UP() -> RT_KEY_GET_SHIFT() > > In both cases, it's called when key > tree->ctl->max_val. Since the > minimum value of max_val is 255, RT_KEY_GET_SHIFT() is never called > when key=0. Ah, right, so it is dead code. Nothing to worry about, but it does point the way to some simplifications, which I've put together in the attached. > > - RT_DELETE: "if (key > tree->ctl->max_val)" is not covered: > > > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L2644 > > > > That should be easy to add. > > Agreed. The patch is attached. LGTM > > - TidStoreCreate* has some memory clamps that are not covered: > > > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/access/common/tidstore.c.gcov.html#L179 > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/access/common/tidstore.c.gcov.html#L234 > > > > Maybe we could experiment with using 1MB for shared, and something > > smaller for local. > > I've confirmed that the local and shared tidstore with small max sizes > such as 4kB and 1MB worked. Currently the max size is hard-coded in > test_tidstore.c but if we use work_mem as the max size, we can pass > different max sizes for local and shared in the test script. Seems okay, do you want to try that and see how it looks?
Вложения
В списке pgsql-hackers по дате отправления: