Skip to content

Mark the Postgres CALL…RETURN timing case as an xfail for #420, as the MERGE case is - #425

Merged
jasperblues merged 1 commit into
mainfrom
xfail-420-call-return
Nov 5, 2026
Merged

jasperblues merged 1 commit into
mainfrom
xfail-420-call-return

Conversation

@jasperblues

Copy link
Copy Markdown
Member

Part of #420.

CompiledWriteLoopTimeTest's Postgres CALL…RETURN case now fails CI reliably on Python 3.13. It took 36.8 s, then 36.5 s, over 20,000 rows against a bound of about 19 s, on #424 and on its rerun.

drivine4j#609 found the cause, a second one under #420. The compiled CALL joins its one-row list (jsonb_array_elements(cy_rows)) to the node table for each row. Postgres estimates the list at 100 rows and may pick a hash join over a scan of every node.

This marks that one case, Postgres CALL…RETURN only, as a non-strict xfail citing #420, the same way the MERGE case is marked. The port of drivine4j#609's fix takes both marks off.

Gate

  • ruff check, ruff format, pyright and unasync --check: clean.
  • Both timing files, on the test box: 16 passed, 2 xfailed (MERGE) and 2 xpassed (CALL…RETURN at 0.6 s there).
  • One review pass, clean.

…e MERGE case is

drivine4j#609 found a second cause of #420: a CALL joins its one-row
list to the node table for each row, and Postgres, taking the list for
100 rows, may scan every node for it. drivine-python CI now fails the
sync case on Python 3.13 (36.8 s and 36.5 s over 20,000 rows). The mark
is not strict, as the MERGE one isn't, and comes off with #420's fix.
@jasperblues
jasperblues merged commit 2cfaab2 into main Nov 5, 2026
7 checks passed
@jasperblues
jasperblues deleted the xfail-420-call-return branch November 5, 2026 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant