Re: Proposal for disk quota feature

2018-08-30 16:22 GMT+02:00 Chapman Flack <chap(at)anastigmatix(dot)net>:

> On 08/30/2018 09:57 AM, Hubert Zhang wrote:
>
> > 2 Keep one worker process for each database. But using a parent/global
> > quota worker process to manage the lifecycle of database level worker
> > processes. It could handle the newly created database(avoid restart
> > database) and save resource when a database is not used. But this needs
> to
> > change worker process to be hierarchical. Postmaster becomes the
> grandfather
> > of database level worker processes in this case.
>
> I am using background workers this way in 9.5 at $work.
>
> In my case, one worker lives forever, wakes up on a set period, and
> starts a short-lived worker for every database, waiting for each
> one before starting the next.
>
> It was straightforward to implement. Looking back over the code,
> I see the global worker assigns its own PID to worker.bgw_notify_pid
> of each of its children, and also obtains a handle for each child
> from RegisterDynamicBackgroundWorker().
>
> I imagine the global quota worker would prefer to start workers
> for every database and then just wait for notifications from any
> of them, but that seems equally straightforward at first glance.
>

There are servers with thousands databases. Worker per database is not good
idea.

It should to share ideas, code with autovacuum process.

Not sure, how to effective implementation based on bg workers can be. On
servers with large set of databases, large set of tables it can identify
too big table too late.

Isn't better to implement some quotas on storage level?

Regards

Pavel

> -Chap
>
>