-
Notifications
You must be signed in to change notification settings - Fork 848
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
Add timescaledb_information.jobs view #2417
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -69,6 +69,27 @@ CREATE OR REPLACE VIEW timescaledb_information.policy_stats as | |
INNER JOIN _timescaledb_internal.bgw_job_stat js on j.id = js.job_id | ||
ORDER BY ht.schema_name, ht.table_name; | ||
|
||
-- view for background worker jobs | ||
CREATE OR REPLACE VIEW timescaledb_information.jobs AS | ||
SELECT j.id AS job_id, | ||
j.application_name, | ||
j.schedule_interval, | ||
j.max_runtime, | ||
j.max_retries, | ||
j.retry_period, | ||
j.proc_schema, | ||
j.proc_name, | ||
j.owner, | ||
j.scheduled, | ||
j.config, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I notice we're writing the entire jobs table except There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hypertable_id is completely internal and may point to internal hypertables There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, I do still think including the table name would be useful, though definitely less so when it points to an internal table. Right now if a user creates two policies with the same parameters, there is no way for them to tell from this new view which job is for which table. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. in case of caggs this points to the materialization hypertable, i guess showing the name would be nice but what would you call the columns? for caggs we should resolve to the cagg view name which means we couldnt call the column hypertable_schema/name There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's actually okay to use the materialization hypertable for caggs as the continuous_aggregates information view also shows the materialization_hypertable, and can be used to match the job to the cagg view name. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok added hypertable name and schema |
||
js.next_start, | ||
ht.schema_name AS hypertable_schema, | ||
ht.table_name AS hypertable_name | ||
FROM _timescaledb_config.bgw_job j | ||
LEFT JOIN _timescaledb_catalog.hypertable ht ON ht.id = j.hypertable_id | ||
LEFT JOIN _timescaledb_internal.bgw_job_stat js ON js.job_id = j.id | ||
ORDER BY j.id; | ||
|
||
-- views for continuous aggregate queries --- | ||
CREATE OR REPLACE VIEW timescaledb_information.continuous_aggregates as | ||
SELECT format('%1$I.%2$I', cagg.user_view_schema, cagg.user_view_name)::regclass as view_name, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be named policies instead? We now have 2 views related to jobs: one is called jobs and the other is called policy stats. Since the primary use case is for setting up policies, I suggest we rename this as timescaledb_information.policies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the distinction i tried to introduce between job/policy is that job is something that is handled by the scheduler and it doesnt matter what it does, while policies are concrete implementations that have a specific purpose, so in that sense both should use job since the have nothing policy-specific in them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then policy_stats should be renamed to job_stats. Also better to get wider input on the name so that we don't have to back and revise it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would prefer job then it would also follow our catalog names, but keeping that job/policy distinction in mind i guess the new feature could also be called custom policies