I wish more applications would adopt the "H" option that Jenkins uses in it's cron notation - essentially it is a randomiser, based on some sort of deterministic hashing function. So you say you want this job to run hourly and it will always run at the same minute past the hour, but you don't know (or care) what that minute that is. Designed to prevent the thundering herd problem with scheduled work.
I use fqdn_rand [1] in puppet for most cron jobs - it allows to run cron jobs at different time on different hosts (with different FQDN) but with the consistent interval between job runs. I would expect any modern configuration management system to have something like that.
Since at least two people noticed, I would just say that the insert-select-insert approach was added later, after I took some inspiration from Django's implementation of get_or_create.
If you store large jsonb values in the database, storing them out of line may be a good thing - for example, you can query metadata much faster.
Also, worth mentioning that jsonb is only benefitial when you plan on indexing/manipulating the data in the database. Otherwise, using json type may be a better choice (smaller size, stored as text, parsed on demand)
We have a habbit of never scheduling long running processes at round hours. Usually because they tend to be busier.
https://hakibenita.com/sql-tricks-application-dba#dont-sched...
reply