Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gRnxg-0006TI-VM for pgsql-performance@arkaria.postgresql.org; Wed, 28 Nov 2018 00:44:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gRnxe-00088Y-B7 for pgsql-performance@arkaria.postgresql.org; Wed, 28 Nov 2018 00:44:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gRnxd-00088R-N0 for pgsql-performance@lists.postgresql.org; Wed, 28 Nov 2018 00:44:14 +0000 Received: from mail-it1-x141.google.com ([2607:f8b0:4864:20::141]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gRnxW-0004Ly-A5 for pgsql-performance@lists.postgresql.org; Wed, 28 Nov 2018 00:44:12 +0000 Received: by mail-it1-x141.google.com with SMTP id m8so3258497itk.0 for ; Tue, 27 Nov 2018 16:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ggWHZQTfpk9n9oxGWA62PJ0j7SaXQlmw0PFcHJKXnG0=; b=cOPJcAsxCLXGh5BBjCLpWyfi93eUUOp0Cqr3SWP0dzG0CY+7uXJ4S5PlTMthcIj2Zf WJdevZUC1aqHUWzkLlpgM3QcRU8nbyb4B3DYvu0LcZRWoiQgDSWdmduTzWGqqtgnWfEP J0m2vQlrhMMrMxFfxEmrrfqVf+ocwLNkikhW08OyQC0AckLDTfqieay6ByEk/OCUD5Td mIglrLqZDrdPv4EegKTdjmuiahB9XBRtMfaBisA4/CT2BiFLD1EQLpmydJiCGJGQCGvS wHlYdmT5vNTHDH6RHaIP7Eyt+fkNjGrmSMMBaWef7xW/juzra+9IXkGb8ed5a0mdXe9G kQ2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ggWHZQTfpk9n9oxGWA62PJ0j7SaXQlmw0PFcHJKXnG0=; b=G/0uiNgruZjzon3XlQ7xDPyyEryAK52m6vbxuF1m8mjipLpEb12r3jOEqazMvxqtCW naHiad4ys2ZIpY9398h7dUtogGePNKVg0M1eiA9aUc2VyRdtZsjcDFUwnj9s4YzoK4mp 81MSzoBW4LNwFskp8CCMCl7iu1CdL6CZWE72UynzCvtmk/RZFDKxGu/eMUocSppQmSxW f9YVty1up8y+on8GeNUF7PA+vMIA45Gy7M6fQHR/7k+6CSmA25stDbeAn1EX9MtnA9Ub 89L2HwrWp1WkEMkQyuCuksUCqw2fZD3ivkIEX+qG1d9uZ2Mu0YwA99xOuqC4jIOFW4yH m/QQ== X-Gm-Message-State: AA+aEWbKKmOU13XS4bEvJDPLdJ4CVTlKDJDlLfSwLCChlxj84E/nl3ST Y426JHLlUB7G0+oiJ6pQxOSHQw== X-Google-Smtp-Source: AFSGD/X2LegnDfPr+hN2+6dZCwlX6MAebzyFfMu7lt01GkOlo/H17bctCcABIyu+6uCzVeian+vKdw== X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr1101440itd.148.1543365845141; Tue, 27 Nov 2018 16:44:05 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id j133sm366961itj.16.2018.11.27.16.44.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 16:44:04 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 0D49A8023CC; Tue, 27 Nov 2018 18:44:02 -0600 (CST) Date: Tue, 27 Nov 2018 18:44:02 -0600 From: Justin Pryzby To: Sanyo Moura 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: <20181128004402.GC30707@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Nov 27, 2018 at 9:17 AM 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. I was able to reproduce this behavior. For my version of the query: On PG10.6 | Result (cost=0.00..0.00 rows=0 width=24) | One-Time Filter: false |Time: 408.335 ms On PG11.1 | Result (cost=0.00..0.00 rows=0 width=24) | One-Time Filter: false |Time: 37487.364 ms (00:37.487) Perf shows me: 47.83% postmaster postgres [.] bms_overlap 45.30% postmaster postgres [.] add_child_rel_equivalences 1.26% postmaster postgres [.] generate_join_implied_equalities_for_ecs CREATE TABLE producto (pluid int unique); CREATE TABLE almacen (loccd int unique); CREATE TABLE precio(fecha timestamp, pluid int, loccd int, plusalesprice int) PARTITION BY RANGE (fecha); SELECT 'CREATE TABLE public.precio_'||i||' PARTITION OF public.precio (PRIMARY KEY (fecha, pluid, loccd), CONSTRAINT precio_20170301_almacen_fk FOREIGN KEY (loccd) REFERENCES public.almacen (loccd) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT precio_20170301_producto_fk FOREIGN KEY (pluid) REFERENCES public.producto (pluid) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION) FOR VALUES FROM ('''||a||''')TO('''||b||''') TABLESPACE pg_default' FROM (SELECT '1990-01-01'::timestamp+(i||'days')::interval a, '1990-01-02'::timestamp+(i||'days')::interval b, i FROM generate_series(1,999) i)x; \gexec \timing explain SELECT l_variacao.fecha, l_variacao.loccd , l_variacao.pant , l_variacao.patual , max_variacao.var_max FROM (SELECT p.fecha, p.loccd, p.plusalesprice patual, da.plusalesprice pant, abs(p.plusalesprice - da.plusalesprice) as var from precio p, (SELECT p.fecha, p.plusalesprice, p.loccd from precio p WHERE p.fecha between '2017-03-01' and '2017-03-02' and p.pluid = 2) da WHERE p.fecha between '2017-03-01' and '2017-03-02' and p.pluid = 2 and p.loccd = da.loccd and p.fecha = da.fecha) l_variacao, (SELECT max(abs(p.plusalesprice - da.plusalesprice)) as var_max from precio p, (SELECT p.fecha, p.plusalesprice, p.loccd from precio p WHERE p.fecha between '2017-03-01' and '2017-03-02' and p.pluid = 2) da WHERE p.fecha between '2017-03-01' and '2017-03-02' and p.pluid = 2 and p.loccd = da.loccd and p.fecha = da.fecha) max_variacao WHERE max_variacao.var_max = l_variacao.var; Since I don't know the original table definitions, I removed two "+1" from the given sql to avoid: "ERROR: operator does not exist: timestamp without time zone + integer" Justin