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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
