Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > The launcher is a dummy process; it never connects to any database.
> > ... Eventually this will need to
> > be changed so that the launcher tells the worker exactly what table to
> > work on.
>
> I detect a certain lack of clarity of thinking here. Either the
> launcher can read databases or it can't. Do you intend to solve the
> problem of all the transaction/catcache infrastructure being designed
> on the assumption of being in exactly one database?
I had the same thought, but then I realized that most of the needed data
is actually stored in pgstat, so we don't need to connect to any
database to get it. (Hmm, except pg_class.reltuples).
What will probably live in databases will be the scheduling catalogs,
but I think I suggested that we could solve that problem by storing the
contents of those in plain text files, like pg_database.
I don't think this is a fundamental problem with the current patch
though. I've refrained from committing it mostly because I'd like
someone else to eyeball it just for safety, so I'll still allow for
several days to pass (unless there is a rush for getting it in ...)
> 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.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.