From d33cf3c6ec89f9fc06fe6ed44954f516a18ddb79 Mon Sep 17 00:00:00 2001 From: Tam Nguyen Duc <1218621+tamnd@users.noreply.github.com> Date: Tue, 18 Aug 2026 11:21:59 +0700 Subject: [PATCH] the appender gate is about batching, not about a disk The test that says an appender beats INSERT asked for twenty times and got eighteen on a CI runner, where a commit costs twenty five milliseconds of a disk shared with everybody else and the appender's single commit is most of what it spends. The same comparison is 150 times on a laptop, and it rises with the row count either way, because one commit is one commit however many rows it carries. Five is the gate now, which is the number that says the rows were batched rather than committed one at a time, and is not a number a slow disk can take away. Raising the row count instead would buy a wider margin at the price of seconds of INSERT per run, since that half is three seconds at two hundred rows here. --- tests/test_appender.py | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/tests/test_appender.py b/tests/test_appender.py index 2cf252a..6f3ed24 100644 --- a/tests/test_appender.py +++ b/tests/test_appender.py @@ -454,8 +454,11 @@ def test_appending_beats_inserting_by_the_margin_that_makes_it_worth_having( # Measured at about 150 times on this machine at this row count and # rising with it, since one commit is one commit however many rows - # it carries. The gate is 20, which is the number that says the - # appender is still batching rather than the number it hits. - assert inserting > 20 * appending, ( + # it carries. It is 18 on a shared CI runner, where a commit costs + # 25 ms of somebody else's disk and the appender's single one is + # most of what it spends, so the gate is 5: the number that says the + # appender is still batching rather than the number either machine + # hits. + assert inserting > 5 * appending, ( f"{COMPARED} rows: {inserting * 1000:.0f} ms inserted, {appending * 1000:.0f} ms appended" )