Hi,
On 07/23/2010 09:45 PM, Dimitri Fontaine wrote:
Yeah, I guess user daemons would have to be workers, not plugins you
want to load into the coordinator.
Okay.
On the other side, the background workers have a connection to exactly
one database. They are supposed to do work on that database.
Is that because of the way backends are started, and to avoid having to
fork new ones too often?
For one, yes, I want to avoid having to start ones too often. I did look
into letting these background workers switch the database connection,
but that turned out not to be worth the effort.
Would you prefer a background worker that's not connected to a database,
or why are you asking?
The background workers can easily load external libraries - just as a
normal backend can with LOAD. That would also provide better
encapsulation (i.e. an error would only tear down that backend, not the
coordinator). You'd certainly have to communicate between the
coordinator and the background worker. I'm not sure how match that fits
your use case.
Pretty well I think.
Go ahead, re-use the background workers. That's what I've published them
for ;-)
Yeah. The connection pool is better outside of code. Let's think PGQ and
a internal task scheduler first, if we think at any generalisation.
To be honest, I still don't quite grok the concept behind PGQ. So I
cannot really comment on this.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
