Thread: Re: [pgsql-patches] Autovacuum launcher patch

Re: [pgsql-patches] Autovacuum launcher patch

From
Markus Schiltknecht
Date:
Alvaro Herrera wrote:
>> I'd suggest sticking to something closer to the current two-phase design
>> where you make some preliminary decision which database to send a worker
>> to, and then the worker determines exactly what to do once it can look
>> around inside the DB.  Possibly we need some back-signaling mechanism
>> whereby a worker can tell the launcher "hey boss, send help" if it sees
>> that there are enough tables that need work, but I'm unenthused about
>> having the launcher figure that out itself.
> 
> Hmm, yeah, we'll probably need some communication channel eventually.

Maybe my IMessages code could be of use?

It's still awfully slow compared with UNIX pipes or even System V IPC 
message queues, since it uses LWLocks for sending and retrieving 
messages. That could certainly be optimized, maybe even towards a 
lock-free implementation, which could theoretically be as fast as System 
V IPC messages. OTOH, such stuff is hard to get right.

Regards

Markus


Re: [pgsql-patches] Autovacuum launcher patch

From
Alvaro Herrera
Date:
Markus Schiltknecht wrote:
> Alvaro Herrera wrote:
> >>I'd suggest sticking to something closer to the current two-phase design
> >>where you make some preliminary decision which database to send a worker
> >>to, and then the worker determines exactly what to do once it can look
> >>around inside the DB.  Possibly we need some back-signaling mechanism
> >>whereby a worker can tell the launcher "hey boss, send help" if it sees
> >>that there are enough tables that need work, but I'm unenthused about
> >>having the launcher figure that out itself.
> >
> >Hmm, yeah, we'll probably need some communication channel eventually.
> 
> Maybe my IMessages code could be of use?
> 
> It's still awfully slow compared with UNIX pipes or even System V IPC 
> message queues, since it uses LWLocks for sending and retrieving 
> messages. That could certainly be optimized, maybe even towards a 
> lock-free implementation, which could theoretically be as fast as System 
> V IPC messages. OTOH, such stuff is hard to get right.

Hmm, I remember eyeballing that code.  Would you mind sending me an URL
to that file, or something?  Or maybe send me the files themselves?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.