On Fri, May 30, 2025 at 02:22 Andrei Lepikhov <lepi...@gmail.com> wrote:
> On 5/30/25 03:17, Nikolay Samokhvalov wrote: > > On Thu, Jun 6, 2024 at 5:31 AM Dmitry Dolgov <9erthali...@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. >
