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
-
Postpone generating tlists and EC members for inheritance dummy children.
- b10e3bba8673 11.2 landed
- 8d8dcead1295 12.0 landed
-
Allow direct lookups of AppendRelInfo by child relid
- 7d872c91a3f9 11.0 cited