Hi David,
On Mon, Aug 2, 2021 at 11:59 AM Amit Langote <amitlangote09@gmail.com> wrote:
> On Sun, Aug 1, 2021 at 9:31 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > On Fri, 30 Jul 2021 at 19:10, Amit Langote <amitlangote09@gmail.com> wrote:
> > > interleaved_parts idea looks clever. I wonder if you decided that
> > > it's maybe not worth setting that field in the joinrel's
> > > PartitionBoundInfos? For example, adding the code that you added in
> > > create_list_bounds() also in merge_list_bounds().
> >
> > Currently generate_orderedappend_paths() only checks
> > partitions_are_ordered() for base and other member rels, so setting
> > the field for join rels would be a waste of effort given that it's not
> > used for anything.
> >
> > I've not really looked into the possibility of enabling this
> > optimization for partition-wise joined rels. I know that there's a bit
> > more complexity now due to c8434d64c. I'm not really all that clear on
> > which cases could be allowed here and which couldn't. It would require
> > more analysis and I'd say that's a different patch.
>
> Yeah, that makes sense.
Related to the above, I noticed while looking at
build_merged_partition_bounds() that db632fbca3 missed adding a line
to that function to set interleaved_parts to NULL. Because the
PartitionBoundInfo is only palloc'd (not palloc0'd), interleaved_parts
of a "merged" bounds struct ends up pointing to garbage, so let's fix
that. Attached a patch.
--
Amit Langote
EDB: http://www.enterprisedb.com