(2018/01/16 1:47), Robert Haas wrote:
On Mon, Jan 15, 2018 at 3:09 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Yeah, but I don't think the above example is good enough to explain that,
because I think the bar/baz join would produce at most one tuple in an EPQ
recheck since we would have only one EPQ tuple for both bar and baz in that
recheck, and the join is inner. I think such an example would probably be
given e.g., by a modified version of the SQL where we have a full join of
bar and baz, not an inner join.
Hmm, I was thinking that bar and baz wouldn't be constrained to return
just one tuple in that case, but I'm wrong: there would just be one
tuple per relation in that case. However, that would also be true for
a full join, wouldn't it?
Consider:
postgres=# create table bar (a int, b text);
postgres=# create table baz (a int, b text);
postgres=# insert into bar values (1, 'bar');
postgres=# insert into baz values (2, 'baz');
postgres=# select * from bar full join baz on bar.a = baz.a;
a | b | a | b
---+-----+---+-----
1 | bar | |
| | 2 | baz
(2 rows)
Both relations have one tuple, but the full join produces two join
tuples. I think it would be possible that something like this happens
when executing a local join plan for a foreign join that performs a full
join remotely.
Regardless of that, the patch fixes the reported problem with very
little code change, and somebody can always improve it further later.
Agreed.
Best regards,
Etsuro Fujita
