Re: generic plans and "initial" pruning

On Fri, Dec 2, 2022 at 7:40 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Dec 1, 2022 at 9:43 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Thu, Dec 1, 2022 at 8:21 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > > On 2022-Dec-01, Amit Langote wrote:
> > > > Hmm, how about keeping the [Merge]Append's parent relation's RT index
> > > > in the PartitionPruneInfo and passing it down to
> > > > ExecInitPartitionPruning() from ExecInit[Merge]Append() for
> > > > cross-checking? Both Append and MergeAppend already have a
> > > > 'apprelids' field that we can save a copy of in the
> > > > PartitionPruneInfo. Tried that in the attached delta patch.
> > >
> > > Ah yeah, that sounds about what I was thinking. I've merged that in and
> > > pushed to github, which had a strange pg_upgrade failure on Windows
> > > mentioning log files that were not captured by the CI tooling. So I
> > > pushed another one trying to grab those files, in case it wasn't an
> > > one-off failure. It's running now:
> > > https://cirrus-ci.com/task/5857239638999040
> > >
> > > If all goes well with this run, I'll get this 0001 pushed.
> >
> > Thanks for pushing 0001.
> >
> > Rebased 0002 attached.
>
> Thought it might be good for PartitionPruneResult to also have
> root_parent_relids that matches with the corresponding
> PartitionPruneInfo. ExecInitPartitionPruning() does a sanity check
> that the root_parent_relids of a given pair of PartitionPrune{Info |
> Result} match.
>
> Posting the patch separately as the attached 0002, just in case you
> might think that the extra cross-checking would be an overkill.

Rebased over 92c4dafe1eed and fixed some factual mistakes in the
comment above ExecutorDoInitialPruning().

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com