MIME-Version: 1.0
References: <CA+HiwqFfAY_ZFqN8wcAEMw71T9hM_kA8UtyHaZZEZtuT3UyogA@mail.gmail.com>
 <68f3771f-91f5-4cb7-b1de-74d9abbf0b96@vondra.me> <CA+HiwqGqeS_94wxiYa8VpymiR_OtFPKDSpX+Me=MYWO45f5yig@mail.gmail.com>
 <dbce8def-e817-4e70-a9cb-e62574724d95@vondra.me> <CA+HiwqGM0ZTeVHicSkGnCp-2U-jvU-KBQCkPJ0N7nAj_c2LjZg@mail.gmail.com>
 <CA+HiwqHyE7-oOvtZ+OC-4N7DvKSr8Jbu75erMLQ7O4d6gfkBhg@mail.gmail.com>
 <CA+HiwqEPMwhg6pUE4XML2rG4fRqKMpeGTtMwRPGes90f9iOqtg@mail.gmail.com>
 <CA+HiwqEZja5rJ78p3FBDZNvynWsHwanxyt6h0YaK_r84NemXng@mail.gmail.com>
 <tencent_B45268659AF0400F68EC1643950ABB6A1B09@qq.com> <CAJDiXggP41+-HrRzT+BmtgmS8wkoZM7b4skkQA5NAe+NFEMPSQ@mail.gmail.com>
In-Reply-To: <CAJDiXggP41+-HrRzT+BmtgmS8wkoZM7b4skkQA5NAe+NFEMPSQ@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Tue, 27 Jan 2026 12:00:13 +0900
Message-ID: <CA+HiwqGufj46_4kT6z5nQrCOxp3rcMDR8fn_t33n2pDKokNRQg@mail.gmail.com>
Subject: Re: Batching in executor
To: Daniil Davydov <3danissimo@gmail.com>
Cc: cca5507 <2624345507@qq.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, Tomas Vondra <tomas@vondra.me>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BHiwqGufj46_4kT6z5nQrCOxp3rcMDR8fn_t33n2pDKokNRQg%40mail.gmail.com>
Precedence: bulk

Hi,

On Mon, Jan 26, 2026 at 6:34=E2=80=AFPM Daniil Davydov <3danissimo@gmail.co=
m> wrote:
>
> Hi,
>
> On Mon, Dec 22, 2025 at 6:46=E2=80=AFPM cca5507 <2624345507@qq.com> wrote=
:
> >
> > Some comments for v4:
> >
>
> Agree with your (1)-(4) comments.
>
> > 5) heapgettup_pagemode_batch()
> > If the scan key filters out all tuples on a page, we may return 0 befor=
e reaching the end of scan, right?
> >
>
> Yes. I think that we should advance to the next page if "nout =3D=3D 0"
> at the end of walking through the rs_vistuples.

Next version (v5) does it like that.

> > 6) heap_begin_batch()
> > ```
> >         hb =3D palloc(sizeof(HeapBatch));
> >         hb->tupdata =3D palloc(sizeof(HeapTupleData) * maxitems);
> > ```
> > Can we just use one palloc() for cache-friendly?
> >
>
> Actually, we are using memory context when calling the palloc function.
> I.e. in the general case it will not cause memory allocation. But of cour=
se
> there is no guarantee for it. I saw a lot of places in the code where we
> are calling the palloc function several times in a row, so I guess that
> this is OK.
>
> If you will decide to leave these palloc calls, I suggest using the
> palloc_object/palloc_array functions.

I think combining those individual pallocs into one is a good idea, so
v5 does it like that.

> A few other comments on 0001 patch:
>
> 1)
> +    void       *(*scan_begin_batch)(TableScanDesc sscan, int maxitems);
> Is it syntactically correct?

Yes, it compiles fine. Though I'm considering changing the return type
to a struct with common fields (like nitems) so callers can access
them directly without callback indirection.  Maybe call it TAMBatch or
something.

> 2)
>     /* Initialize static fields of HeapTupleData. Row bodies remain on pa=
ge. */
>     relid =3D RelationGetRelid(sscan->rs_rd);
>     for (int i =3D 0; i < maxitems; i++)
>         hb->tupdata[i].t_tableOid =3D relid;
>
> Is it really necessary? I see that we are setting this field inside the
> heapgettup_pagemode_batch function.

It's intentional -- by initializing t_tableOid once in
heap_begin_batch, we can avoid setting it repeatedly for every tuple
in heapgettup_pagemode_batch().  Though you are correct to point out
the redundant assignment in heapgettup_pagemode_batch(); I'll change
it to an Assert instead. The relid doesn't change during the scan.

> A few comment on 0002 patch:
>
> 1)
> I guess that you should rebase your patches on the current master, becaus=
e
> the second patch doesn't apply.

Yep, will do.

> 2)
> Maybe we can use tuplestore for tuples stored in TupleBatch? It is just a
> proposal - I didn't check this idea carefully.

TupleBatch is designed to be lightweight -- it holds an array of
TupleTableSlot pointers, not the tuple data itself. The slots
reference tuples that remain in the AM's buffer (no copy). Using
tuplestore would require materializing tuples, adding overhead we're
trying to avoid.

--=20
Thanks, Amit Langote