From: | Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance regression with PostgreSQL 11 and partitioning |
Date: | 2018-05-25 16:53:17 |
Message-ID: | 2b3def41-938f-2eff-6643-29c4ce000549@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(dot)reiss(at)dalibo(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-05-25 17:53:37 | Re: Performance regression with PostgreSQL 11 and partitioning |
Previous Message | Robert Haas | 2018-05-25 16:18:29 | Re: Enhancement Idea - Expose the active value of a parameter in pg_settings |