| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Using per-transaction memory contexts for storing decoded tuples |
| Date: | 2024-10-03 18:32:44 |
| Message-ID: | CAD21AoAHnr9pjcRvC4m2zfH=T=33U-Qwc4GqJjBBOcJbYGCu_g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 3, 2024 at 2:46 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-10-03 18:35:24 | Re: allowing extensions to control planner behavior |
| Previous Message | Robert Haas | 2024-10-03 18:24:01 | Re: On disable_cost |