Re: Using per-transaction memory contexts for storing decoded tuples - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Using per-transaction memory contexts for storing decoded tuples
Date
Msg-id CAD21AoAHnr9pjcRvC4m2zfH=T=33U-Qwc4GqJjBBOcJbYGCu_g@mail.gmail.com
Whole thread Raw
In response to Re: Using per-transaction memory contexts for storing decoded tuples  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Using per-transaction memory contexts for storing decoded tuples
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: On disable_cost
Next
From: Robert Haas
Date:
Subject: Re: allowing extensions to control planner behavior