Re: [HACKERS] postgres_fdw bug in 9.6
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] postgres_fdw bug in 9.6 |
Дата | |
Msg-id | 25125.1516069059@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] postgres_fdw bug in 9.6 (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] postgres_fdw bug in 9.6
|
Список | pgsql-hackers |
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes: > (2018/01/16 1:47), Robert Haas wrote: >> 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. Doesn't really matter though, does it? Each of those join rows will be processed as a separate EPQ event. regards, tom lane
В списке pgsql-hackers по дате отправления: