Thread: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
postgres_fdw.c around line 4500:
/* * If there is a possibility that EvalPlanQual will be executed, we need * to be able to reconstruct the row
usingscans of the base relations. * GetExistingLocalJoinPath will find a suitable path for this purpose in * the
pathlist of the joinrel, if one exists. We must be careful to * call it before adding any ForeignPath, since the
ForeignPathmight * dominate the only suitable local path available. We also do it before
--> * reconstruct the row for EvalPlanQual(). Find an alternative local path * calling foreign_join_ok(), since
thatfunction updates fpinfo and marks * it as pushable if the join is found to be pushable. */
Should the marked line simply be deleted? If not, what correction is
appropriate?
regards, tom lane
On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > postgres_fdw.c around line 4500: > > /* > * If there is a possibility that EvalPlanQual will be executed, we need > * to be able to reconstruct the row using scans of the base relations. > * GetExistingLocalJoinPath will find a suitable path for this purpose in > * the path list of the joinrel, if one exists. We must be careful to > * call it before adding any ForeignPath, since the ForeignPath might > * dominate the only suitable local path available. We also do it before > --> * reconstruct the row for EvalPlanQual(). Find an alternative local path > * calling foreign_join_ok(), since that function updates fpinfo and marks > * it as pushable if the join is found to be pushable. > */ > > Should the marked line simply be deleted? If not, what correction is > appropriate? Hmm, wow. My first thought was that it should just say "reconstructing" rather than "reconstruct", but on further reading I think you might have the right idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> --> * reconstruct the row for EvalPlanQual(). Find an alternative local path
>> Should the marked line simply be deleted? If not, what correction is
>> appropriate?
> Hmm, wow. My first thought was that it should just say
> "reconstructing" rather than "reconstruct", but on further reading I
> think you might have the right idea.
The current text of the comment dates to commit 177c56d60, and looking at
that commit makes it pretty clear that the line I'm complaining of
belonged to the previous text; it evidently just missed getting deleted.
regards, tom lane
On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> --> * reconstruct the row for EvalPlanQual(). Find an alternative local path >>> Should the marked line simply be deleted? If not, what correction is >>> appropriate? > >> Hmm, wow. My first thought was that it should just say >> "reconstructing" rather than "reconstruct", but on further reading I >> think you might have the right idea. > > The current text of the comment dates to commit 177c56d60, and looking at > that commit makes it pretty clear that the line I'm complaining of > belonged to the previous text; it evidently just missed getting deleted. Got it. Nice forensics, and sorry about the good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> --> * reconstruct the row for EvalPlanQual(). Find an alternative local path >>>> Should the marked line simply be deleted? If not, what correction is >>>> appropriate? >> >>> Hmm, wow. My first thought was that it should just say >>> "reconstructing" rather than "reconstruct", but on further reading I >>> think you might have the right idea. >> >> The current text of the comment dates to commit 177c56d60, and looking at >> that commit makes it pretty clear that the line I'm complaining of >> belonged to the previous text; it evidently just missed getting deleted. > > Got it. Nice forensics, and sorry about the good. ... goof. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The current text of the comment dates to commit 177c56d60, and looking at
>>> that commit makes it pretty clear that the line I'm complaining of
>>> belonged to the previous text; it evidently just missed getting deleted.
>> Got it. Nice forensics, and sorry about the good.
> ... goof.
Will you fix it, or shall I?
regards, tom lane
On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> The current text of the comment dates to commit 177c56d60, and looking at >>>> that commit makes it pretty clear that the line I'm complaining of >>>> belonged to the previous text; it evidently just missed getting deleted. > >>> Got it. Nice forensics, and sorry about the good. > >> ... goof. > > Will you fix it, or shall I? Whichever you like. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Will you fix it, or shall I?
> Whichever you like.
It's your commit, you can do the honors.
regards, tom lane
On 2017/08/17 1:31, Tom Lane wrote: > postgres_fdw.c around line 4500: > > /* > * If there is a possibility that EvalPlanQual will be executed, we need > * to be able to reconstruct the row using scans of the base relations. > * GetExistingLocalJoinPath will find a suitable path for this purpose in > * the path list of the joinrel, if one exists. We must be careful to > * call it before adding any ForeignPath, since the ForeignPath might > * dominate the only suitable local path available. We also do it before > --> * reconstruct the row for EvalPlanQual(). Find an alternative local path > * calling foreign_join_ok(), since that function updates fpinfo and marks > * it as pushable if the join is found to be pushable. > */ > > Should the marked line simply be deleted? If not, what correction is > appropriate? In relation to this, I updated the patch for addressing the GetExistingLocalJoinPath issue [1]. Best regards, Etsuro Fujita [1] https://www.postgresql.org/message-id/6008ca34-906f-e61d-478b-8f85fde2c090%40lab.ntt.co.jp