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
>

Reply via email to