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. > > ... The definition of interleaved > > + * is any partition that can contain multiple different values where > > exists at > > + * least one other partition which could contain a value which is between > > the > > + * multiple possible values in the other partition. > > > > The sentence sounds a bit off starting at "...where exists". How about: > > I must have spent too long writing SQL queries. Hah. > I had another self review of these and I'm pretty happy with them. I'm > quite glad to see the performance of querying a single partition of a > table with large numbers of partitions no longer tails off as much as > it used to. Nice, glad to see the apply_scanjoin_target_to_paths() loop taken care of. Thank you. -- Amit Langote EDB: http://www.enterprisedb.com
