Date: Tue, 27 Nov 2018 15:10:22 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Sanyo Moura <sanyo.moura@tatic.net>
Cc: jeff.janes@gmail.com, pgsql-performance@lists.postgresql.org
Subject: Re: Query with high planning time at version 11.1 compared versions
 10.5 and 11.0
Message-ID: <20181127211022.GA30707@telsasoft.com>
References: 
 <CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR+pqjF=rmKBTgpw@mail.gmail.com>
 <CAMkU=1wb5JqO9jCgp-3q-40X7c+AtTGw=CZzqF8+iBmua+geVg@mail.gmail.com>
 <CAO698qZRB020VM53gU6EHEM2QcAUE=GxvMS5rWLWBnNE2ACoPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAO698qZRB020VM53gU6EHEM2QcAUE=GxvMS5rWLWBnNE2ACoPA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk

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