From: Justin Pryzby <pryzby@telsasoft.com>
To: Sanyo Moura <sanyo.moura@tatic.net>
Cc: jeff.janes@gmail.com
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Date: Tue, 27 Nov 2018 18:44:02 -0600
Message-ID: <20181128004402.GC30707@telsasoft.com> (raw)
In-Reply-To: <CAO698qZRB020VM53gU6EHEM2QcAUE=GxvMS5rWLWBnNE2ACoPA@mail.gmail.com>
References: <CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR+pqjF=rmKBTgpw@mail.gmail.com>
<CAMkU=1wb5JqO9jCgp-3q-40X7c+AtTGw=CZzqF8+iBmua+geVg@mail.gmail.com>
<CAO698qZRB020VM53gU6EHEM2QcAUE=GxvMS5rWLWBnNE2ACoPA@mail.gmail.com>
On Tue, Nov 27, 2018 at 9:17 AM Sanyo Moura <sanyo.moura@tatic.net> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pryzby@telsasoft.com, sanyo.moura@tatic.net, 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
In-Reply-To: <20181128004402.GC30707@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox