On Fri, May 25, 2018 at 10:30 AM, Thomas Reiss <thomas.re...@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
