[ sorry for slow response, this month has been mostly crazy ] Antonin Houska <antonin.hou...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers