Streaming module for Teradata profiler extracts - #2649
Open
dey-abhishek wants to merge 2 commits into
Open
Conversation
TeradataConnector now implements the streaming interface: SQL steps pull results in bounded fetchmany() batches (4096 rows) instead of buffering the whole set. Each batch is an Arrow table whose schema is derived once from the cursor description, so every batch of a query shares one schema even when a column is all-NULL in a given batch. DECIMAL columns are carried as exact text (no float rounding of large counters) and tz-aware datetimes are normalized to UTC-naive. Also bump the core DBQL lookback from 7 to 30 days.
…ically Teradata was never registered in SOURCE_SYSTEM_VARIANTS, so --variant is ignored. Drop the stale flag from the run command and rewrite the 'Choosing a Profiler Variant' section as 'Workload Extraction': one run extracts core DBQL and additionally attempts PDCR, with the optional PDCR steps skipped automatically when PDCRINFO is absent.
|
|
dey-abhishek
added a commit
that referenced
this pull request
Aug 31, 2026
The teradata.mdx updates (parameter reference and the --variant correction) move out of the parameterization branch; docs are handled on the streaming branch (#2649). This branch is now code-only.
6 tasks
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2649 +/- ##
==========================================
- Coverage 71.25% 71.19% -0.06%
==========================================
Files 112 112
Lines 10119 10173 +54
Branches 1111 1122 +11
==========================================
+ Hits 7210 7243 +33
- Misses 2695 2715 +20
- Partials 214 215 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
dey-abhishek
added a commit
that referenced
this pull request
Aug 31, 2026
Add the profiler settings prompts to the configure-database-profiler example and document the five bind parameters (lookback_days, pdcr_lookback_days, sys_usage_lookback_days, sys_nodes_lookback_days, max_rows) with their SQL predicates and defaults. The --variant/Workload-Extraction doc corrections are handled separately on the streaming branch (#2649).
|
✅ 181/181 passed, 8 flaky, 2 skipped, 1h21m38s total Flaky tests:
Running from acceptance #5419 |
Contributor
Author
|
@asnare - Could you review the PR and share your feedback/approval |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
What does this PR do?
Streams Teradata profiler extracts instead of buffering the whole result set in memory, and bumps the core DBQL look-back window from 7 to 30 days.
TeradataConnectornow implements the streaming interface (supports_streaming()→True), so the pipeline pulls each SQL step's results in boundedfetchmany()batches (4096 rows) rather than materializing the entire set. This keeps peak memory flat for large DBQL extracts. Snowflake already streamed; this brings Teradata onto the same path (the pipeline's_stream_sql_steprouting and the base interface already exist onmain).Relevant implementation details
type_codeas the Python type it returns; the schema is derived once fromcursor.descriptionand reused for every batch, so batches stay schema-identical even when a column is all-NULL in a given batch (the pipeline appends batches positionally into the DDL-pre-created DuckDB table).DECIMALcolumns are carried as exact text (notfloat64) so a counter past2**53doesn't round; DuckDB casts the string back. tz-aware datetimes (fromTIMESTAMP WITH TIME ZONE) are normalized to UTC-naive so they don't get rejected against the tz-naive batch schema._STREAM_BATCH_ROWS = 4096.CURRENT_DATE - INTERVAL '30' DAY(was'7'); theTOP 100000row cap is unchanged.Docs
--variant(it was never registered inSOURCE_SYSTEM_VARIANTS), so the stale flag is dropped from the run command and the "Choosing a Profiler Variant" section is rewritten as "Workload Extraction" — a single run extracts the core DBQL workload and additionally attempts PDCR, with the optional PDCR steps skipped automatically whenPDCRINFOis absent.Functionality
Tests
DECIMALexactness, tz-aware normalization, unknown-type-code fallbackmake fmtclean (black/ruff/mypy, pylint 10.00/10) andmake testpassingABSENT) wherePDCRINFOis absent, and the streamed DuckDB extract is schema-identical to prior buffered runs (release 0.14.2/0.13.0). Row-level comparison against a buffered run confirms streaming loses/alters nothing: the static/inventory tables (td_db_object_types,td_dwh_udf,td_sys_info,td_sys_nodes_info,td_user_databases) are byte-identical row-for-row; the streamedtd_dbql_core_info_extractis a strict superset of the earlier run (every earlier row present, extras are only newer live-log queries — 0 rows dropped); and the only remaining deltas are same-key value drift in the inherently time-varying tables (td_sys_disk_utilizationpoint-in-time usage,td_sys_usage_aggre-aggregatedResUsageSpmabuckets) — no rows lost, added, or retyped by streaming