| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com>, "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 19:05:42 |
| Message-ID: | CA+TgmoZwbR-2fc_71nZ82si5K=mbV+7PpRsqy9cP2LBj-TNtBQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | Postg토토 핫SQL : |
On Fri, May 25, 2018 at 1:53 PM, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> Seems here that we call find_appinfos_by_relids here for *all*
> partitions, even if all but one partition may have been pruned. I
> haven't studied this code in detail, but I suspect it might be
> unnecessary, although I might be wrong.
Uggh. It might be possible to skip it for dummy children. That would
leave the dummy child rels generating a different pathtarget than the
non-dummy children, but I guess if we never use them again maybe it
wouldn't matter.
> Fwiw, I'm not sure why the new pruning code would call here, at least
> git grep find_appinfos_by_relids doesn't turn up anything interesting
> in that regard.
Hmm, OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chapman Flack | 2018-05-25 20:32:45 | Re: SPI/backend equivalent of extended-query Describe(statement)? |
| Previous Message | Bruce Momjian | 2018-05-25 19:04:45 | Re: perlcritic and perltidy |