From: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Append implementation |
Date: | 2017-04-18 06:48:18 |
Message-ID: | CAJ3gD9cWhwkJLzW0b_bYpbg5wrMWy3wuXogNAVQ+SE_XkYxhRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7 April 2017 at 20:35, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> But for costs such as (4, 4, 4, .... 20 times), the logic would give
>> us 20 workers because we want to finish the Append in 4 time units;
>> and this what we want to avoid when we go with
>> don't-allocate-too-many-workers approach.
>
> I guess, my problem is that I don't agree with that as a goal in an of
> itself. If you actually want to run your query quickly, you *want* 20
> workers here. The issues of backend startup overhead (already via
> parallel_setup_cost), concurrency and such cost should be modelled, not
> burried in a formula the user can't change. If we want to make it less
> and less likely to start more workers we should make that configurable,
> not the default.
> I think there's some precedent taken from the parallel seqscan case,
> that's not actually applicable here. Parallel seqscans have a good
> amount of shared state, both on the kernel and pg side, and that shared
> state reduces gains of increasing the number of workers. But with
> non-partial scans such shared state largely doesn't exist.
After searching through earlier mails about parallel scan, I am not
sure whether the shared state was considered to be a potential factor
that might reduce parallel query gains, when deciding the calculation
for number of workers for a parallel seq scan. I mean even today if we
allocate 10 workers as against a calculated 4 workers count for a
parallel seq scan, they might help. I think it's just that we don't
know if they would *always* help or it would regress sometimes.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-04-18 06:51:00 | Re: On How To Shorten the Steep Learning Curve Towards PG Hacking... |
Previous Message | Kang Yuzhe | 2017-04-18 06:45:01 | Re: On How To Shorten the Steep Learning Curve Towards PG Hacking... |