pgsql: Fix hashjoin costing mistake introduced with inner_unique optimi

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix hashjoin costing mistake introduced with inner_unique optimi
Date: 2018-07-14 15:59:24
Message-ID: E1feMxA-0005UV-EM@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix hashjoin costing mistake introduced with inner_unique optimization.

In final_cost_hashjoin(), commit 9c7f5229a allowed inner_unique cases
to follow a code path previously used only for SEMI/ANTI joins; but it
neglected to fix an if-test within that path that assumed SEMI and ANTI
were the only possible cases. This resulted in a wrong value for
hashjointuples, and an ensuing bad cost estimate, for inner_unique normal
joins. Fortunately, for inner_unique normal joins we can assume the number
of joined tuples is the same as for a SEMI join; so there's no need for
more code, we just have to invert the test to check for ANTI not SEMI.

It turns out that in two contrib tests in which commit 9c7f5229a
changed the plan expected for a query, the change was actually wrong
and induced by this estimation error, not by any real improvement.
Hence this patch also reverts those changes.

Per report from RK Korlapati. Backpatch to v10 where the error was
introduced.

David Rowley

Discussion: https://postgr.es/m/CA+SNy03bhq0fodsfOkeWDCreNjJVjsdHwUsb7AG=jpe0PtZc_g@mail.gmail.com

Branch
------
REL_10_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/0bb28ca36eaf14ba73695bc0a29e3f36de34e07b

Modified Files
--------------
contrib/citext/expected/citext.out | 2 +-
contrib/citext/expected/citext_1.out | 2 +-
contrib/postgres_fdw/expected/postgres_fdw.out | 19 +++++++++++--------
src/backend/optimizer/path/costsize.c | 6 +++---
4 files changed, 16 insertions(+), 13 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-07-14 18:16:45 YA race condition in 001_stream_rep.pl (was Re: pgsql: Allow using the updated tuple while moving it to a different par)
Previous Message Michael Paquier 2018-07-14 12:18:50 Re: pgsql: Fix FK checks of TRUNCATE involving partitioned tables