Thread

Re: Proposal: Job Scheduler

Nikolay Samokhvalov <nik@postgres.ai> — 2025-05-30T14:11:08Z

On Fri, May 30, 2025 at 02:22 Andrei Lepikhov <lepihov@gmail.com> wrote:

> On 5/30/25 03:17, Nikolay Samokhvalov wrote:
> > On Thu, Jun 6, 2024 at 5:31 AM Dmitry Dolgov <9erthalion6@gmail.com
> >     +1. The PostgreSQL ecosystem is surprisingly fragmented, when it
> comes
> >     to quite essential components that happen to be outside of the core.
> But
> >     of course it doesn't mean that there should be _one_ component of
> every
> >     kind in core, more like it makes sense to have _one_ component
> available
> >     out of the box (where the box is whatever form of PostgreSQL that
> gets
> >     delivered to users, e.g. a distro package, container, etc.).
> >
> >
> > +1 too.
> >
> > There is a huge reason to have a job scheduler in core – new partition
> > creation.
> >
> > In my opinion, partitioning in Postgres needs more automation, and new
> > partition creation is a big missing piece. And it does require a
> scheduler.
> >
> > I like pg_timetable a lot, but it's written in Go;
> >
> > pg_cron is written in Go, and it's already present in most managed
> > Postgres platforms. Why not to bring it to Postgres core so we could
> > then use it to improve developer experience of dealing with partitioning?
> I would say you should provide a reason why it is too difficult to stay
> outside the core, such as pg_hint_plan or a similar feature.
> In my opinion, the main reason to push an extension into contrib is if
> it has a strong connection with the core API. But the scheduler seems as
> far from the volatile API features as possible.
> That's more, contrib extensions have essential priority to external
> solutions and reduce development impulse in the area.



I'm not proposing to include it as contrib module -- I propose to include
it to core code base and then use to implement automated partition creation.

>