> On Jun 4, 2020, at 3:03 PM, Sebastian Dressler wrote:
>
> Hi Philip,
>
>> On 4. Jun 2020, at 20:37, Philip Semanchuk
>> wrote:
>>
>> [...]
>>>
This brings up a couple of questions —
1) I’ve read that this is Postgres’ formula for the max # of workers it
will consider for
Hi Philip,
On 4. Jun 2020, at 20:37, Philip Semanchuk
mailto:phi...@americanefficient.com>> wrote:
[...]
This brings up a couple of questions —
1) I’ve read that this is Postgres’ formula for the max # of workers it will
consider for a table —
max_workers = log3(table size / min_parallel_tab
> On Jun 4, 2020, at 1:45 PM, Sebastian Dressler wrote:
>
> Hi Philip,
>
>> On 4. Jun 2020, at 18:41, Philip Semanchuk
>> wrote:
>> [...]
>>
>>> Also, there are more configuration settings related to parallel queries you
>>> might want to look into. Most notably:
>>>
>>> parallel_setup_c
Hi Philip,
On 4. Jun 2020, at 18:41, Philip Semanchuk
mailto:phi...@americanefficient.com>> wrote:
[...]
Also, there are more configuration settings related to parallel queries you
might want to look into. Most notably:
parallel_setup_cost
parallel_tuple_cost
min_parallel_table_scan_size
Espe
> On Jun 4, 2020, at 2:28 AM, Sebastian Dressler wrote:
>
> Hi Philip,
>
>> On 4. Jun 2020, at 00:23, Philip Semanchuk
>> wrote:
>>
>>> I guess you should show an explain analyze, specifically "Workers
>>> Planned/Launched", maybe by linking to explain.depesz.com
>>
>> Out of an abundance
On Thu, Jun 4, 2020 at 12:24 AM Philip Semanchuk <
phi...@americanefficient.com> wrote:
>
>
> > On Jun 3, 2020, at 5:15 PM, Justin Pryzby wrote:
> >
> > On Wed, Jun 03, 2020 at 04:04:13PM -0400, Philip Semanchuk wrote:
> >> Can anyone help me understand why this happens, or where I might look
> f
On Wed, Jun 03, 2020 at 06:23:57PM -0400, Philip Semanchuk wrote:
...
I then ran the EXPLAIN ANALYZE and got the same slow runtime (1473s) and 1
worker in the EXPLAIN ANALYZE output.
I guess you should show an explain analyze, specifically "Workers
Planned/Launched", maybe by linking to exp
