On Fri, May 25, 2018 at 05:17:12PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Fri, May 25, 2018 at 1:53 PM, Amit Langote <amitlangot...@gmail.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.
> Maybe it's all right to decide that this rejiggering can be left > for v12 ... did we promise anyone that it's now sane to use thousands > of partitions? https://www.postgresql.org/docs/devel/static/ddl-partitioning.html |The following caveats apply to CONSTRAINT EXCLUSION: |[...] |All constraints on all partitions of the master table are examined during |constraint exclusion, so large numbers of partitions are likely to increase |query planning time considerably. So the legacy inheritance based partitioning |will work well with up to perhaps a hundred partitions; DON'T TRY TO USE MANY |THOUSANDS OF PARTITIONS. It doesn't matter for us, as we're already using tooo many partitions, but I would interpret that to mean that thousands of partitions are a job exclusively for "partition pruning" of declarative partitions. Justin