Re: [PoC] Improve dead tuple storage for lazy vacuum
От | Masahiko Sawada |
---|---|
Тема | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Дата | |
Msg-id | CAD21AoDgfezAPZZxxhKV7wCHpf2Hk6LV0zbog-1g_ssZZ+um5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Improve dead tuple storage for lazy vacuum (John Naylor <johncnaylorls@gmail.com>) |
Ответы |
Re: [PoC] Improve dead tuple storage for lazy vacuum
Re: [PoC] Improve dead tuple storage for lazy vacuum |
Список | pgsql-hackers |
On Wed, Jan 17, 2024 at 9:20 AM John Naylor <johncnaylorls@gmail.com> wrote: > > On Tue, Jan 16, 2024 at 1:18 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > Just changing "items" to be the local tidstore struct could make the > > code tricky a bit, since max_bytes and num_items are on the shared > > memory while "items" is a local pointer to the shared tidstore. > > Thanks for trying it this way! I like the overall simplification but > this aspect is not great. > Hmm, I wonder if that's a side-effect of the "create" functions doing > their own allocations and returning a pointer. Would it be less tricky > if the structs were declared where we need them and passed to "init" > functions? Seems worth trying. The current RT_CREATE() API is also convenient as other data structure such as simplehash.h and dshash.c supports a similar > > That may be a good idea for other reasons. It's awkward that the > create function is declared like this: > > #ifdef RT_SHMEM > RT_SCOPE RT_RADIX_TREE *RT_CREATE(MemoryContext ctx, Size max_bytes, > dsa_area *dsa, > int tranche_id); > #else > RT_SCOPE RT_RADIX_TREE *RT_CREATE(MemoryContext ctx, Size max_bytes); > #endif > > An init function wouldn't need these parameters: it could look at the > passed struct to know what to do. But the init function would initialize leaf_ctx etc,no? Initializing leaf_ctx needs max_bytes that is not stored in RT_RADIX_TREE. The same is true for dsa. I imagined that an init function would allocate a DSA memory for the control object. So I imagine we will end up still requiring some of them. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: