> On Thu, Jun 06, 2024 at 12:53:38PM GMT, Alvaro Herrera wrote: > On 2024-Jun-06, Dave Page wrote: > > > It's this kind of choice that means it's unlikely we'd include any one > > option in PostgreSQL, much like various other tools such as failover > > managers or poolers. > > TBH I see that more as a bug than as a feature, and I see the fact that > there are so many schedulers as a process failure. If we could have > _one_ scheduler in core that encompassed all the important features of > all the independent ones we have, with hooks or whatever to allow the > user to add any fringe features they need, that would probably lead to > less duplicative code and divergent UIs, and would be better for users > overall. > > That's, of course, just my personal opinion.
+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?
