aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/expected
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-07-14 11:59:12 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-07-14 11:59:12 -0400
commit0bb28ca36eaf14ba73695bc0a29e3f36de34e07b (patch)
treecdd0a274212c93a17d58b4945f0c4aeda8b2cde3 /contrib/postgres_fdw/expected
parent1f47eb08cb42986f1f0c6ef52156f55ba9f7b1a3 (diff)
downloadpostgresql-0bb28ca36eaf14ba73695bc0a29e3f36de34e07b.tar.gz
postgresql-0bb28ca36eaf14ba73695bc0a29e3f36de34e07b.zip
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
Diffstat (limited to 'contrib/postgres_fdw/expected')
-rw-r--r--contrib/postgres_fdw/expected/postgres_fdw.out19
1 files changed, 11 insertions, 8 deletions
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index 9c0328eb63c..f6bb2fc472c 100644
--- a/contrib/postgres_fdw/expected/postgres_fdw.out
+++ b/contrib/postgres_fdw/expected/postgres_fdw.out
@@ -4226,18 +4226,21 @@ explain (verbose, costs off) select * from ft3 where f2 = 'foo' COLLATE "C";
explain (verbose, costs off) select * from ft3 f, loct3 l
where f.f3 = l.f3 COLLATE "POSIX" and l.f1 = 'foo';
- QUERY PLAN
----------------------------------------------------------
- Nested Loop
+ QUERY PLAN
+-------------------------------------------------------------
+ Hash Join
Output: f.f1, f.f2, f.f3, l.f1, l.f2, l.f3
- Join Filter: ((f.f3)::text = (l.f3)::text)
- -> Index Scan using loct3_f1_key on public.loct3 l
- Output: l.f1, l.f2, l.f3
- Index Cond: (l.f1 = 'foo'::text)
+ Inner Unique: true
+ Hash Cond: ((f.f3)::text = (l.f3)::text)
-> Foreign Scan on public.ft3 f
Output: f.f1, f.f2, f.f3
Remote SQL: SELECT f1, f2, f3 FROM public.loct3
-(9 rows)
+ -> Hash
+ Output: l.f1, l.f2, l.f3
+ -> Index Scan using loct3_f1_key on public.loct3 l
+ Output: l.f1, l.f2, l.f3
+ Index Cond: (l.f1 = 'foo'::text)
+(12 rows)
-- ===================================================================
-- test writable foreign table stuff