From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, 花田茂 <shigeru(dot)hanada(at)gmail(dot)com> |
Subject: | Re: Foreign join pushdown vs EvalPlanQual |
Date: | 2015-09-29 17:49:38 |
Message-ID: | CA+TgmoY30Sefj7MGfx2QvRD_K=kwmKTBJ+shx3LV5PXkp7ZYtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 29, 2015 at 4:49 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> Also note that EvalPlanQualFetchRowMarks() will raise an error
> if RefetchForeignRow callback returned NULL tuple.
> Is it right or expected behavior?
That's not how I read the code. If RefetchForeignRow returns NULL, we
just ignore the row and continue on to the next one:
if (copyTuple == NULL)
{
/* couldn't get the lock, so skip this row */
goto lnext;
}
And that seems exactly right: RefetchForeignRow needs to test that the
tuple is still present on the remote side, and that any remote quals
are matched. If either of those is false, it can return NULL.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2015-09-29 17:52:46 | Re: On-demand running query plans using auto_explain and signals |
Previous Message | Tom Lane | 2015-09-29 17:46:13 | Re: No Issue Tracker - Say it Ain't So! |