From: | Andrew Borodin <borodin(at)octonica(dot)com> |
---|---|
To: | Andrew Borodin <amborodin(at)acm(dot)org> |
Cc: | amul sul <sulamul(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_background contrib module proposal |
Date: | 2016-12-09 12:48:18 |
Message-ID: | CAJEAwVF2MY+-HnFLD=1Ygtm5yfgEEkRTZy+Ob-HDG=Wcdf4d_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-09 12:52:50 | Re: Time to drop old-style (V0) functions? |
Previous Message | Amit Langote | 2016-12-09 12:11:43 | Re: Declarative partitioning - another take |