| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical Replication WIP |
| Date: | 2016-08-09 20:31:02 |
| Message-ID: | 20160809203102.GA582807@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Petr Jelinek wrote:
> On 09/08/16 12:16, Craig Ringer wrote:
> >Right. I think that's probably the direction we should be going
> >eventually. Personally I don't think such a change should block the
> >logical replication work from proceeding with bgworkers, though.
>
> Yeah that's why I added local max GUC that just handles the logical worker
> limit within the max_worker_processes. I didn't want to also write generic
> framework for managing the max workers using tags or something as part of
> this, it's big enough as it is and we can always move the limit to the more
> generic place once we have it.
Parallel query does exactly that: the workers are allocated from the
bgworkers array, and if you want more, it's on you to increase that
limit (it doesn't even have the GUC for a maximum). As far as logical
replication and parallel query are concerned, that's fine. We can
improve this later, if it proves to be a problem.
I think there are far more pressing matters to review.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2016-08-09 20:32:44 | Re: Logical Replication WIP |
| Previous Message | Robert Haas | 2016-08-09 20:19:21 | Re: Oddity in EXPLAIN for foreign/custom join pushdown plans |