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>
 <CA+HiwqGufj46_4kT6z5nQrCOxp3rcMDR8fn_t33n2pDKokNRQg@mail.gmail.com> <CA+HiwqH-2GmTKLW9kHdnqV4KdFiPfuAdVK2TgqOM2JaaeUYXnw@mail.gmail.com>
In-Reply-To: <CA+HiwqH-2GmTKLW9kHdnqV4KdFiPfuAdVK2TgqOM2JaaeUYXnw@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Thu, 29 Jan 2026 11:04:17 +0100
Message-ID: <CA+HiwqHcoc4a053OmghKWiZXKJFwtDbfqrobF659mSxZiZYv-A@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%2BHiwqHcoc4a053OmghKWiZXKJFwtDbfqrobF659mSxZiZYv-A%40mail.gmail.com>
Precedence: bulk

On Thu, Jan 29, 2026 at 8:35=E2=80=AFAM Amit Langote <amitlangote09@gmail.c=
om> wrote:
>
> Hi,
>
> Here is v5 of the patch series.
>
> Patches 0001-0003 add the core batching infrastructure. 0001 adds the
> batch table AM API with heapam implementation, 0002 wires up SeqScan
> to use it (still returning one slot at a time), and 0003 adds EXPLAIN
> (BATCHES). I'd love to hear people's thoughts around TupleBatch
> structure added in 0002. I thought about making it a separate patch so
> that 0002 will still populate the single ScanState.ss_scanTupleSlot,
> but that means we'd still have to call the TAM callback to populate
> the tuple in the TAM's batch struct into the slot, defeating the whole
> point. With TupleBatch, you have executor_batch_rows number of slots
> which are filled in one TAM callback (materialize_all) call. So I
> decided to keep the TupleBatch and related things in 0002.
>
> For scans without quals, batching shows 20-30% improvement with no
> visible regressions when batching is disabled (batch_rows=3D0):
>
> SELECT * FROM t LIMIT n (no qual)
>
>   Rows      Master    batch=3D0   %diff    batch=3D64  %diff
>   ------   --------   -------   -----    --------  -----
>   1M        12.42 ms  11.96 ms   3.7%     8.56 ms  31.0%
>   3M        38.95 ms  38.92 ms   0.1%    28.59 ms  26.6%
>   10M      153.64 ms 150.28 ms   2.2%   112.95 ms  26.5%
>
> (%diff: positive =3D faster than master, negative =3D slower)

Oops, I meant SELECT * FROM t LIMIT 1 OFFSET n (no qual).

--=20
Thanks, Amit Langote