You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 44077a0
Browse filesBrowse the repository at this point in the historyBrowse files
perf(thrift): read the reply in 1 MiB chunks instead of buffering it whole
Reading the whole body in flush() held a second copy of it during decode
and, on urllib3 1.26, turned a truncated 503/429 body into a ProtocolError
that skipped the status-based retry. The transport now refills from urllib3
in 1 MiB chunks (or a whole field if larger), like TBufferedTransport, so
truncated bodies fail inside decode as on main. Peak heap for a 100 MiB
multi-batch reply drops from ~200 to ~103 MiB at the same speed.
Tests now run the decode paths under both the C and the pure-Python
protocol, and cover the truncated-503 retry.
Signed-off-by: Vu Anh Phung <vu.phung@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
# Unreleased
4
4
- Fix inline parameters (`use_inline_params=True`) so a sequence directly after `IN` renders as a list again: `x IN %(ids)s` renders as `x IN (1,2,3)` instead of `x IN ARRAY(1,2,3)`, which Spark rejects. Inside the list, tuples render as rows for a multi-column `IN`, and a `set` or `frozenset` is accepted again. Sequences anywhere else still render as `ARRAY(...)` ([#629](https://github.com/databricks/databricks-sql-python/issues/629))
5
-
- Speed up Thrift response handling: decode replies from a buffered body with Thrift's C-accelerated protocol, and stop stringifying every request/response for the default no-op debug logger. Wide result schemas, metadata calls with many rows, and inline Arrow results benefit most.
5
+
- Speed up Thrift response handling: read replies in 1 MiB chunks and decode them with Thrift's C-accelerated protocol, and stop stringifying every request/response for the default no-op debug logger. Wide result schemas, metadata calls with many rows, and inline Arrow results benefit most.
6
6
7
7
# 4.9.0 (2026-11-04)
8
8
- Upgrade Databricks SQL Kernel to 1.4.0, which keeps Lakehouse Real-Time session affinity and flushes shared telemetry only after the final session closes.
0 commit comments