David Rowley <david.row...@2ndquadrant.com> writes: > On 31 January 2017 at 04:56, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I'm not following. If the join removal code had reached the stage of >> making a uniqueness check, and that check had succeeded, the join would be >> gone and there would be no repeat check later. If it didn't reach the >> stage of making a uniqueness check, then again there's no duplication.
> I had forgotten the unique check was performed last. In that case the > check for unused columns is duplicated needlessly each time. I think we do need to repeat that each time, as columns that were formerly used in a join condition to a now-dropped relation might thereby have become unused. > But let's > drop it, as putting the code back is not making things any worse. Agreed, if there is something to be won there, we can address it separately. > I don't think that's possible. The whole point that the current join > removal code retries to remove joins which it already tried to remove, > after a successful removal is exactly because it is possible for a > join to become provability unique on the removal of another join. Not seeing that ... example please? > If you remove that retry code, a regression test fails. Probably because of the point about unused columns... regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers