Shorter iterations of join_info_list
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.
One possible use case could be
placeholder.c:update_placeholder_eval_levels():
1. The first (in terms of position in join_info_list) join above
phinfo->ph_var->phrels can be marked as the (exclusive) upper bound for
all iterations.
2. The first join for which particular iteration of SJ infos
identifies the necessity to extend eval_at can be marked in
join_info_list as (exclusive) lower bound for the next iteration. This
is because that addition can only affect parents of the join whose
relations we just added to eval_at. And these essentially can't be
located at lower positions in join_info_list.
The lower limit could also be used in initsplan.c:check_outerjoin_delay().
Is this worth a patch? It's not much coding but I'd appreciate some
feedback before I try to do anything.
Thanks,
Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[ 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers