Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Sanyo Moura <sanyo.moura@tatic.net>
Cc: jeff.janes@gmail.com, pgsql-performance@lists.postgresql.org
Date: 2018-11-27T21:10:22Z
Lists: pgsql-hackers, pgsql-performance
On Tue, Nov 27, 2018 at 06:30:04PM -0200, Sanyo Moura wrote: >>> I'm running performance tests for my application at version 11.1 and >>> encountered >>> queries with high planning time compared to the same planning, running at >>> versions 10.5 and 11.0. > > Below is the script that creates one partition table: Would you send the CREATE TABLE or \d for precio, produto, and almacen ? Are the 2 referenced tables also empty or can you reproduce the problem if they are (like in a separate database) ? Do you still have an instance running 10.5 ? Or did you find the planning time in logs (like autoexplain) ? Are any of your catalog tables bloated or indexes fragmented ? I assume catalog tables and their indices should all be much smaller than shared_buffers. SELECT relpages, relname FROM pg_class WHERE relnamespace='pg_catalog'::regnamespace ORDER BY 1 DESC LIMIT 9; Can you compare pg_settings between the servers ? Either from a live server or historic postgresql.conf or from memory if need be. https://wiki.postgresql.org/wiki/Server_Configuration Justin
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