simple patch for discussion - Mailing list pgsql-hackers

From Greg Hennessy
Subject simple patch for discussion
Date
Msg-id c5143c6c-44e8-45b3-861c-d5935d8c6ad9@gmail.com
Whole thread Raw
Responses Re: simple patch for discussion
List pgsql-hackers
This is my first attempt for a patch to postgresql, please forgive me if 
I have forgotten some step.

I recently got a new system, with many more CPU cores than previous 
systems than I am used to, 128 cores
(which may not seem a large number to some). I was a bit unhappy that 
even though I configured max_worker_processes
and max_parallel_workers to values above 90, my queries were only 
allocating 10 workers, and with fiddling
with min_parallel_table_scan_size and min_parallel_index_scan_size I 
could get it to 14 or so, the algorithm in allpaths.c
seems to base the number of workers on the log3 of the ratio of the 
buffer size and the table/index scan size. I sugguest
replacing this with the square root of the ratio, which grows faster 
than the log3. My thought is that there are ways
to configure postgresql so it won't allocate an excessive number of 
workers, but there isn't an easy way to get more
workers.

I enclose the patch for consideration. My understanding is that a lot of 
work is going into getting V19 ready,
if people would prefer to wait for that before considering my patch I 
understand.

V/r
Greg

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available
Next
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?