Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <pryzby@xxxxxxxxxxxxx> 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 <admad123@xxxxxxxxx> 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

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux