Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

2017-08-17 Thread Etsuro Fujita

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

2017-08-16 Thread Tom Lane
Robert Haas  writes:
> 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

2017-08-16 Thread Robert Haas
On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane  wrote:
> 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

2017-08-16 Thread Tom Lane
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?

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

2017-08-16 Thread Robert Haas
On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas  wrote:
> 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

2017-08-16 Thread Robert Haas
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.

-- 
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

2017-08-16 Thread Tom Lane
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.

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

2017-08-16 Thread Robert Haas
On Wed, Aug 16, 2017 at 12:31 PM, 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?

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

2017-08-16 Thread Tom Lane
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