> I will set aside the code I already rewrote for this purpose, and come
> back to it after we start 7.1.
Wait a minute ... stop the presses ...
I just realized that the bug I was complaining of is *already there
in current sources*, and has been for a while (certainly since 6.5).
Look at prune.c's code that merges together RelOptInfos after-the-
fact:
if (same(rel->relids, unmerged_rel->relids)) { /* * These rels are for the same set
ofbase relations, * so get the best of their pathlists. We assume it's * ok to reassign a path
tothe other RelOptInfo without * doing more than changing its parent pointer (cf. pathnode.c). */
rel->pathlist = add_pathlist(rel, rel->pathlist,
unmerged_rel->pathlist); }
This is wrong, wrong, wrong, because the paths coming from different
RelOptInfos (different pairs of sub-relations) may need different sets
of qual clauses applied as restriction clauses. There's no way to
represent that in the single RelOptInfo that will be left over. The
worst case is that the generated plan is missing a needed restriction
clause (the other possibility is that the clause is evaluated
redundantly, which is much less painful).
I am not sure why we haven't heard bug reports about this. It seems
like it wouldn't be hard at all to provoke the failure (I'm going to
try to make a test case right now). Assuming I can do that, I think
we have no choice but to move join restrictlists into JoinPath nodes.
regards, tom lane