Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
Robert Haaswrites: > On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane wrote: >> Will you fix it, or shall I? > Whichever you like. It's your commit, you can do the honors. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
On Wed, Aug 16, 2017 at 3:44 PM, Tom Lanewrote: > Robert Haas writes: >> On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas wrote: >>> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
Robert Haaswrites: > On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas wrote: >> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
On Wed, Aug 16, 2017 at 3:02 PM, Robert Haaswrote: > On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
On Wed, Aug 16, 2017 at 2:16 PM, Tom Lanewrote: > Robert Haas writes: >> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
Robert Haaswrites: > On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths
On Wed, Aug 16, 2017 at 12:31 PM, Tom Lanewrote: > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[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 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers