Add optional cursor for run_at time on jobs#120
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…_to_lock Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Remove unused job_2 let binding in locker_spec.rb "with run_at_cursor enabled" context - Update CLI description to clarify "due before" instead of "scheduled before" Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…in/lock_job_query Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Do you have a query plan before and after for this? |
I have query plans which include the index hinting we added, which shows lower index read execution when including the run_at cursor. |
|
I'm a bit confused. |
Fair point. It's a boolean when it's being passed to the worker (use or don't use the cursor), then its a timestamp when its the actual cursor value. I'll make the distinction clearer. |
|
oh the specs 🫠 |
…stamp value run_at_cursor is now only used as the boolean feature flag on Locker/Worker. The actual timestamp lower bound passed through the locking methods is renamed run_at_lower_bound to make the distinction clear. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| # For more information, see the 'Predicate Specificity' chapter of: | ||
| # https://brandur.org/postgres-queues | ||
| class Locker | ||
| RUN_AT_CURSOR_RESET = "-infinity" |
There was a problem hiding this comment.
That is a bit confusing, not sure if nil and testing nil will be clearer, can leave it
5 participants
This additional cursor can lead to more dead tuples/tombstones being skipped while acquiring locks on jobs. The cursor is optional, configured behind the
run_at_cursorflag when starting a worker. If not specified therun_atclause will always be set to-infinity, performing the same as if it was not present.