Horton

Re: Using per-transaction memory contexts for storing decoded tuples

Masahiko Sawada <sawada.mshk@gmail.com>

View thread View on postgr.es
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Amit Kapila <amit.kapila16@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-10-03T18:32:44Z
Lists: pgsql-hackers 
On Thu, Oct 3, 2024 at 2:46 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2024/10/03 13:47, Masahiko Sawada wrote:
> >>> I agree that the overhead will be much less visible in real workloads.
> >>> +1 to use a smaller block (i.e. 8kB).
>
> +1
>
>
> >>> It's easy to backpatch to old
> >>> branches (if we agree)
>
> +1
>
>
> >> It seems that
> >> only reorderbuffer.c uses the LARGE macro so that it can be removed.
> >
> > I'm going to keep the LARGE macro since extensions might be using it.
>
> Yes, for the back-patch. But in the master branch,
> we basically don't need to maintain this kind of compatibility?
>

Yes, but as for this macro specifically, I thought that it might be
better to keep it, since it avoids breaking extension unnecessarily
and it seems to be natural to have it as an option for slab context.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Commits

  1. Reduce memory block size for decoded tuple storage to 8kB.

  2. Generational memory allocator