Hi Justin, Yes, force_parallel_mode is on. Should we set it off? Regards, Aditya.
On Sat, Apr 3, 2021 at 7:46 PM Justin Pryzby <pry...@telsasoft.com> wrote: > On Sat, Apr 03, 2021 at 04:08:01PM +0200, Pavel Stehule wrote: > > so 3. 4. 2021 v 15:38 odesÃlatel aditya desai <admad...@gmail.com> > napsal: > > > "Gather (cost=1000.43..1002.75 rows=1 width=127) (actual > > > time=174.318..198.539 rows=1 loops=1)" > > > " Workers Planned: 1" > > > " Workers Launched: 1" > > > " Single Copy: true" > > > " -> Index Scan using address1_i7 on address1 dom (cost=0.43..2.65 > rows=1 > > > width=127) (actual time=0.125..0.125 rows=1 loops=1)" > > > " Index Cond: (address_key = 6113763)" > > > "Planning Time: 0.221 ms" > > > "Execution Time: 198.601 ms" > > > > You should have broken configuration - there is not any reason to start > > parallelism - probably some option in postgresql.conf has very bad > value. > > Second - it's crazy to see 200 ms just on interprocess communication - > > maybe your CPU is overutilized. > > It seems like force_parallel_mode is set, which is for debugging and not > for > "forcing things to go faster". Maybe we should rename the parameter, like > parallel_mode_testing=on. > > http://rhaas.blogspot.com/2018/06/using-forceparallelmode-correctly.html > > -- > Justin >
