2016-12-09 13:48 GMT+01:00 Andrew Borodin <boro...@octonica.com>: > I've read the code and now I have more suggestions. > > 1. Easy one. The case of different natts of expected and acutal result > throws same errmsg as the case of wrong types. > I think we should assist the user more here > > if (natts != tupdesc->natts) > ereport(ERROR, > (errcode(ERRCODE_DATATYPE_MISMATCH), > errmsg("remote query result rowtype does not match the > specified FROM clause rowtype"))); > > and here > > if (type_id != tupdesc->attrs[i]->atttypid) > ereport(ERROR, > (errcode(ERRCODE_DATATYPE_MISMATCH), > errmsg("remote query result rowtype does not match the > specified FROM clause rowtype"))); > > 2. This code > errhint("You may need to increase max_worker_processes.") > Is technically hinting absolutley right. > But this extension requires something like pg_bouncer or what is > called "thread pool". > You just cannot safely fire a background task because you do not know > how many workes can be spawned. Maybe it'd be better to create 'pool' > of workers and form a queue of queries for them? > This will make possible start a millions of subtasks. >
This is not easy, because pgworker is related to database, not to server. There are servers where you can have thousands databases. Regards Pavel > > 3. About getting it to the core, not as an extension. IMO this is too > sharp thing to place it into core, I think that it's best place is in > contribs. > > Thanks for the work on such a cool and fun extension. > > Best regards, Andrey Borodin. > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >