Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Provide query_id in the Adapter Response #892

Open
3 tasks done
KeltonKarboviak opened this issue Jul 31, 2024 · 2 comments · May be fixed by #891
Open
3 tasks done

[Feature] Provide query_id in the Adapter Response #892

KeltonKarboviak opened this issue Jul 31, 2024 · 2 comments · May be fixed by #891
Labels
awaiting_response enhancement New feature or request

Comments

@KeltonKarboviak
Copy link

Is this your first time submitting a feature request?

  • I have read the expectations for open source contributors
  • I have searched the existing issues, and I could not find an existing issue for this feature
  • I am requesting a straightforward extension of existing dbt-redshift functionality, rather than a Big Idea better suited to a discussion

Describe the feature

I want to be able to capture the query ID of the statement used to load a model.

This will be helpful if we ever need to troubleshoot or diagnose a particular model load by taking the query ID and cross-referencing it in the various system tables that give stats & metrics for every query that is run.

Describe alternatives you've considered

I am unsure of an alternative for how to capture the exact query ID that was run for a model besides capturing it in the adapter and providing it in the Adapter Response, which will then save it to the JSON artifacts.

Who will this benefit?

This will be helpful for database administrators, data engineers, and data analysts in needing to troubleshoot or diagnose performance issues with a particular dbt build.

Are you interested in contributing this feature?

Yes

Anything else?

Reference to the dbt-snowflake adapter where they are capturing query_id in the adapter response: https://github.com/dbt-labs/dbt-snowflake/blob/f95b9192f6eec9af4e30eaab87f9e3412febf7d1/dbt/adapters/snowflake/connections.py#L456-L461

@KeltonKarboviak KeltonKarboviak added enhancement New feature or request triage labels Jul 31, 2024
@amychen1776
Copy link

amychen1776 commented Aug 28, 2024

@KeltonKarboviak Thank you for opening this (and the draft PR)! One of the concerns I have with your draft PR is the performance impact for accessing another metadata table as well as the fact that AWS has been recommending that we migrate dependencies off of the pg tables for a bit now. Would you be able to check for performance impact in the PR?

I'm curious of what you think of the alternative approach of tagging query history would also meet your needs?

Copy link
Contributor

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting_response enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants