-
Notifications
You must be signed in to change notification settings - Fork 11
Add the addCronTask helper to make registering cron tasks easier #982
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
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 | ||||
|---|---|---|---|---|---|---|
| @@ -1,7 +1,7 @@ | ||||||
| Vocabulary: tasks | ||||||
|
|
||||||
| Term: id | ||||||
| Concept Type: Big Serial (Type) | ||||||
| Concept Type: Big Serial (Type) | ||||||
| Term: actor | ||||||
| Concept Type: Integer (Type) | ||||||
| Term: attempt count | ||||||
|
|
@@ -31,6 +31,7 @@ Fact type: task has key | |||||
| Fact type: task is created by actor | ||||||
| Necessity: each task is created by exactly one actor | ||||||
| Fact type: task is executed by handler | ||||||
| Synonymous Form: handler executes task | ||||||
| Necessity: each task is executed by exactly one handler | ||||||
| Fact type: task is executed with parameter set | ||||||
| Necessity: each task is executed with at most one parameter set | ||||||
|
|
@@ -53,3 +54,4 @@ Fact type: task has attempt limit | |||||
| Necessity: each task has exactly one attempt limit | ||||||
| Necessity: each task has an attempt limit that is greater than or equal to 1 | ||||||
|
|
||||||
| Rule: It is necessary that each handler that executes a task that is scheduled with a cron expression and has a status that is equal to "queued", executes at most one task that is scheduled with a cron expression and has a status that is equal to "queued". | ||||||
|
Contributor
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 this can be simplified to:
Suggested change
Member
Author
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. @Page- It seems that the affected IDs optimization doesn't like it that rule (I also tried adding a comma, but that lead to "no match" errors): I also realized that this should also work (the sentence makes sense) but SELECT NOT EXISTS (
SELECT "task.1"."is executed by-handler"
FROM "task" AS "task.1"
WHERE TRUE
-- AND "task.1"."is scheduled with-cron expression" IS NOT NULL
-- AND 'queued' = "task.1"."status"
-- AND "task.1"."status" IS NOT NULL
AND (
SELECT COUNT(*)
FROM "task" AS "task.4"
WHERE "task.4"."is scheduled with-cron expression" IS NOT NULL
AND 'queued' = "task.4"."status"
AND "task.4"."status" IS NOT NULL
AND "task.4"."is executed by-handler" = "task.1"."is executed by-handler"
) >= 2
) AS "result";
QUERY PLAN
Result (cost=4.90..4.91 rows=1 width=1) (actual time=25883.233..25883.235 rows=1 loops=1)
Output: (NOT (InitPlan 2).col1)
InitPlan 2
-> Seq Scan on public.task task_1 (cost=0.00..6711290.02 rows=1368708 width=0) (actual time=25883.231..25883.231 rows=0 loops=1)
Filter: ((SubPlan 1) >= 2)
Rows Removed by Filter: 4112852
SubPlan 1
-> Aggregate (cost=1.59..1.60 rows=1 width=8) (actual time=0.006..0.006 rows=1 loops=4112852)
Output: count(*)
-> Index Scan using idx_task_poll on public.task (cost=0.12..1.58 rows=1 width=0) (actual time=0.005..0.005 rows=0 loops=4112852)
Index Cond: ((task."is executed by-handler")::text = (task_1."is executed by-handler")::text)
Filter: (task."is scheduled with-cron expression" IS NOT NULL)
Planning Time: 0.326 ms
Execution Time: 25883.270 mson the other hand w/ the filters present on both sides the query is much faster: QUERY PLAN
Result (cost=3.18..3.19 rows=1 width=1) (actual time=5.364..5.365 rows=1 loops=1)
Output: (NOT (InitPlan 2).col1)
InitPlan 2
-> Index Scan using idx_task_poll on public.task task_1 (cost=0.12..3.18 rows=1 width=0) (actual time=5.362..5.363 rows=0 loops=1)
Filter: ((task_1."is scheduled with-cron expression" IS NOT NULL) AND ((SubPlan 1) >= 2))
SubPlan 1
-> Aggregate (cost=1.59..1.60 rows=1 width=8) (never executed)
Output: count(*)
-> Index Scan using idx_task_poll on public.task (cost=0.12..1.58 rows=1 width=0) (never executed)
Index Cond: ((task."is executed by-handler")::text = (task_1."is executed by-handler")::text)
Filter: (task."is scheduled with-cron expression" IS NOT NULL)
Planning Time: 0.305 ms
Execution Time: 5.393 msb) I followed the pattern that we use in all other cases where we mirror the where clauses in both sides. fwiw, given the benefits of the pattern of having the "where clauses" on both sides & that we use it in all such rules atm, it's the pattern that my partial unique index auto generation PR v is attempting to detect:
Contributor
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. Yeah I realized that it's specifically the pattern of |
||||||
Uh oh!
There was an error while loading. Please reload this page.