Hi David, On Mon, Aug 2, 2021 at 11:59 AM Amit Langote <amitlangot...@gmail.com> wrote: > On Sun, Aug 1, 2021 at 9:31 PM David Rowley <dgrowle...@gmail.com> wrote: > > On Fri, 30 Jul 2021 at 19:10, Amit Langote <amitlangot...@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
initialize-inteleaved_parts.patch
Description: Binary data
