Re: Performance regression with PostgreSQL 11 and partitioning
От | Thomas Reiss |
---|---|
Тема | Re: Performance regression with PostgreSQL 11 and partitioning |
Дата | |
Msg-id | 2b3def41-938f-2eff-6643-29c4ce000549@dalibo.com обсуждение исходный текст |
Ответ на | Re: Performance regression with PostgreSQL 11 and partitioning (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Le 25/05/2018 à 16:49, Robert Haas a écrit : > 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. I didn't because I didn't enough time. I'll take another look next week.
В списке pgsql-hackers по дате отправления: