On Fri, May 25, 2018 at 10:30 AM, Thomas Reiss <thomas.reiss@dalibo.com> wrote:
> Then I used the following to compare the planning time :
> explain (analyze) SELECT * FROM t1 WHERE dt = '2018-05-25';
>
> With PostgreSQL 10, planning time is 66ms, in v11, planning rise to
> 143ms. I also did a little test with more than 20k partitions, and while
> the planning time was reasonable with PG10 (287.453 ms), it exploded
> with v11 with 4578.054 ms.
>
> Perf showed that thes functions find_appinfos_by_relids and
> bms_is_member consumes most of the CPU time with v11. With v10, this
> functions don't appear. It seems that find_appinfos_by_relids was
> introduced by commit 480f1f4329f.
Hmm. Have you verified whether that commit is actually the one that
caused the regression? It's certainly possible, but I wouldn't expect
calling find_appinfos_by_relids() with 1 AppendRelInfo to be too much
more expensive than calling find_childrel_appendrelinfo() as the
previous code did. I wonder if some later change, perhaps related to
pruning, just caused this code path to be hit more often.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
