Mike Freedman

Hi @EmergentCybernetics Yeah, I've heard of others do that as well, and don't see a reason it shouldn't work. Appreciate too this as a tracking issue for the request; you...

> problem with the second behavior is with overlapping jobs. For example, a job scheduled at every minute, but the previous job takes longer than a minute, what do you...

But UNIX cron probably doesn't have the same problem like max_background_workers as the database, and perhaps even worse, doesn't typically deal with the complexities of lock discipline.

For what it's worth, `pg_cron` doesn't support overlapping jobs either. https://github.com/citusdata/pg_cron#what-is-pg_cron > pg_cron can run multiple jobs in parallel, but it runs at most one instance of a job at...

Hi @shaunsales It sounds like you want the "prev" parameter in locf to "look back" out of the range: https://docs.timescale.com/latest/api#locf But from your second argument, it sounds like you are...

We don't typically recommend this because it's actually less efficient, as it can't do chunk exclusion at planning time...because you don't known a priori how "far back" you need to...

Hi @PIdaho would you mind sharing a bit more high-level about the desired functionality that you want, or use case you have? The above feels like it's trying to shoehorn...

It seems like the approach you might prefer is better support for non-hash partitioning, so that you can specify a distinct "space" partitioning by setting some column value, and then...

For some follow-up -- we currently recommend using separate hypertables if you want this functionality, e.g., being able to have different data retention policies. The secondary advantages of separate hypertables...

Hi @leventov pg_prometheus has been sunset for the new system released here, which should be much more performant, has native PromQL support, native compression, and more. It has a very...