[ sorry for slow response, this month has been mostly crazy ]
Antonin Houska <antonin.houska@gmail.com> writes:
> As far as I understand, deconstruct_recurse() ensures that
> SpecialJoinInfo of a new join always gets added to higher position in
> join_info_list than SJ infos of all joins located below the new join in
> the tree. I wonder if we can rely on that fact sometimes.
FWIW, I think of most of those planner lists as being unordered sets.
Depending on a particular ordering definitely adds fragility; so I'd
not want to introduce such a dependency without solid evidence of a
substantial speed improvement. The cases you mention don't seem very
likely to offer any noticeable gain at all --- at least, I don't recall
seeing any of those functions show up high in profiles.
regards, tom lane
