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

aditya desai <admad123@gmail.com>

From: aditya desai <admad123@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>, Pgsql Performance <pgsql-performance@lists.postgresql.org>
Date: 2021-04-03T15:44:33Z
Lists: pgsql-hackers, pgsql-performance
Thanks Justin. Will review all parameters and get back to you.

On Sat, Apr 3, 2021 at 9:11 PM Justin Pryzby <pryzby@telsasoft.com> wrote:

> On Sat, Apr 03, 2021 at 11:39:19AM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > On Sat, Apr  3, 2021 at 08:38:18PM +0530, aditya desai wrote:
> > >> Yes, force_parallel_mode is on. Should we set it off?
> >
> > > Yes.  I bet someone set it without reading our docs:
> >
> > >
> https://www.postgresql.org/docs/13/runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER
> >
> > > --> Allows the use of parallel queries for testing purposes even in
> cases
> > > --> where no performance benefit is expected.
> >
> > > We might need to clarify this sentence to be clearer it is _only_ for
> > > testing.
> >
> > I wonder why it is listed under planner options at all, and not under
> > developer options.
>
> Because it's there to help DBAs catch errors in functions incorrectly
> marked as
> parallel safe.
>
> --
> Justin
>

Commits

  1. Sync guc.c and postgresql.conf.sample with the SGML docs.

  2. doc: Move force_parallel_mode to section for developer options

  3. Move log_autovacuum_min_duration into its correct sections