Re: Performance regression with PostgreSQL 11 and partitioning
Thomas Reiss <thomas.reiss@dalibo.com>
From: Thomas Reiss <thomas.reiss@dalibo.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-05-25T16:53:17Z
Lists: 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.
Commits
-
Fix typo in comment
- f5545287dc5f 11.0 landed
-
Allow direct lookups of AppendRelInfo by child relid
- 7d872c91a3f9 11.0 landed
-
Teach adjust_appendrel_attrs(_multilevel) to do multiple translations.
- 480f1f4329f1 11.0 cited