Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Wed, 29 Aug 2018 at 09:32, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>
> > * Many functions carry some unrelated arguments just to pass them through,
> > which obscures the purpose of a function.
>
> Can you please provide some examples?

E.g this chain with partsupfunc & collations:

partition_range_bounds_merge
-> partition_range_cmp
-> partition_range_bound_cmp
-> partition_range_merge_next_lb

I believe I already mentioned that before (although I'm not saying that I have
a solution right away, it just bothers me).

> > * I want to suggest to introduce a new data structure for partitions mapping
> > instead of just keeping them in arrays (was it discussed already before?).
>
> The best I could think of was a structure with just two arrays. So,
> instead of encapsulating the arrays within a structure, I thought it
> best to pass bare arrays around. If you have any other ideas, please
> let me know.

Well, what I had in mind is something like a structure Mapping with fields from
& to.

> > * What is the reason that almost everywhere in the patch there is a naming
> > convention "outer/inner" partition maps, and sometimes (e.g. in
> > generate_matching_part_pairs) it's "map1/map2"?
>
> You will find that the optimizer in general uses outer/inner,
> rel1/rel2 nomenclature interchangeably. This patch-set just inherits
> that. But yes, we should do more to straighten it out.

Thanks, good to know.

> I won't be working on this actively in the next commitfest. I will be
> glad if somebody else wants to take this up. If there's nobody,
> probably we should mark this entry as "returned with feedback" in the
> next commitfest.

Since I'm more or less familiar with the code and I believe it's an interesting
feature, I can try to take over it for now if you don't mind (but without any
strong commitments to make it perfectly shining for the next CF).