Re: Using per-transaction memory contexts for storing decoded tuples
От | Amit Kapila |
---|---|
Тема | Re: Using per-transaction memory contexts for storing decoded tuples |
Дата | |
Msg-id | CAA4eK1Jug8eewvQT2-YTp2fRSFY9y0Aodeh5bKV=nkUbs_8AGA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using per-transaction memory contexts for storing decoded tuples (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-hackers |
On Fri, Oct 11, 2024 at 3:40 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > Please find the attached patches. > @@ -343,9 +343,9 @@ ReorderBufferAllocate(void) */ buffer->tup_context = GenerationContextCreate(new_ctx, "Tuples", - SLAB_LARGE_BLOCK_SIZE, - SLAB_LARGE_BLOCK_SIZE, - SLAB_LARGE_BLOCK_SIZE); + SLAB_DEFAULT_BLOCK_SIZE, + SLAB_DEFAULT_BLOCK_SIZE, + SLAB_DEFAULT_BLOCK_SIZE); Shouldn't we change the comment atop this change [1] which states that we should benchmark the existing values? One more thing we kept the max size as SLAB_DEFAULT_BLOCK_SIZE instead of something like we do with ALLOCSET_DEFAULT_SIZES, so we can probably write a comment as to why we choose to use the max_size same as init_size. BTW, can we once try to use the max size as SLAB_LARGE_BLOCK_SIZE? Can it lead to the same problem with concurrent transactions where freeing larger blocks could be a problem, if so, we can at least write a comment for future reference. [1] - /* * XXX the allocation sizes used below pre-date generation context's block * growing code. These values should likely be benchmarked and set to * more suitable values. */ -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: