Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

Sanyo Moura <sanyo.moura@tatic.net>

From: Sanyo Moura <sanyo.moura@tatic.net>
To: tgl@sss.pgh.pa.us
Cc: pgsql-performance@lists.postgresql.org
Date: 2018-11-27T15:11:49Z
Lists: pgsql-hackers, pgsql-performance
Hello Tom,

Both versions 10.5 and 11.1 are running on the same test server.
What I did was migrate the database from 10.5 to 11.1 via pg_upgrade. After
successful execution, I performed "vacuumdb --all --analyze-in-stages".

Thanks,

Sanyo Capobiango

Em ter, 27 de nov de 2018 às 13:00, Tom Lane <tgl@sss.pgh.pa.us> escreveu:

> Sanyo Moura <sanyo.moura@tatic.net> writes:
> > And below are the times generated by EXPLAIN ANALYZE:
>
> > 10.5
> > Planning time: 126.080 ms
> > Execution time: 2.306 ms
>
> > 11.0
> > Planning Time: 7.238 ms
> > Planning Time: 2.638 ms
>
> > 11.5        (I assume you mean 11.1 here)
> > Planning Time: 15138.533 ms
> > Execution Time: 2.310 ms
>
> There were no changes between 11.0 and 11.1 that look like they'd affect
> planning time.  Nor does it seem particularly credible that planning time
> would have dropped by a factor of 15 between 10.x and 11.x, especially
> not given that the resulting plan didn't change.  I think you've got some
> external factor causing long planning times --- maybe something taking an
> exclusive lock on one of the tables, or on pg_statistic?
>
>                         regards, tom lane
>

Commits

  1. Postpone generating tlists and EC members for inheritance dummy children.

  2. Allow direct lookups of AppendRelInfo by child relid