of custom-scan (Re: [HACKERS] [v9.5]
Custom
Plan API)
On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
We never guarantee the interface compatibility between major version up.
If we add/modify interface on v9.6, it is duty for developer of extensions
to follow the new
On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
We never guarantee the interface compatibility between major version up.
If we add/modify interface on v9.6, it is duty for developer of extensions
to follow the new version, even not specific to custom-scan provider.
On Tue, Jul 14, 2015 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Both you and Andres have articulated the concern that CustomScan isn't
actually useful, but I still don't really understand why not.
I'm curious, for example, whether CustomScan would
On Wed, Jul 15, 2015 at 2:28 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
We never guarantee the interface compatibility between major version up.
If we add/modify interface on v9.6, it is duty for developer of
On Fri, Jul 10, 2015 at 8:55 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
If somebody still needs it, I'll rebase and adjust the patch towards
the latest custom-scan interface. However, I cannot be motivated for
the feature nobody wants.
Robert, can you weigh in on this? Do we currently have
On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
We don't have anything that currently tests the Custom Scan interface
in the tree. The question is how important that is, and whether it's
worth having what's basically a toy implementation just to demonstrate
Robert Haas robertmh...@gmail.com writes:
Both you and Andres have articulated the concern that CustomScan isn't
actually useful, but I still don't really understand why not.
I'm curious, for example, whether CustomScan would have been
sufficient to build TABLESAMPLE, and if not, why not.
On Tue, Jul 14, 2015 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this ties into my core unhappiness with the customscan stuff,
which is that I don't believe it's *possible* to do anything of very
great interest with it. I think anything really useful will require
core code
Robert Haas wrote:
We don't have anything that currently tests the Custom Scan interface
in the tree. The question is how important that is, and whether it's
worth having what's basically a toy implementation just to demonstrate
that the feature can work. If so, I think ctidscan is as good
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
As a general principle, I think it's a good idea to have a module that's
mostly just a skeleton that guides people into writing something real to
use whatever API is being
(Re: [HACKERS] [v9.5]
Custom
Plan API)
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
As a general principle, I think it's a good idea to have a module that's
mostly just a skeleton that guides people
Or, taking the example of a GpuScan node, it's essentially impossible
to persuade the planner to delegate any expensive function calculations,
aggregates, etc to such a node; much less teach it that that way is cheaper
than doing such things the usual way. So yeah, KaiGai-san may have a
On 07/02/2015 08:21 AM, Kouhei Kaigai wrote:
Folks,
Moved this patch to next CF 2015-02 because of lack of review(ers).
Do we still need this patch as contrib module?
It was originally required it as example of custom-scan interface last
summer, however, here was no strong requirement
: [HACKERS] [v9.5]
Custom
Plan API)
On Tue, Jan 6, 2015 at 10:51 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Jim, Thanks for your reviewing the patch.
The attached patch is revised one according to your suggestion,
and also includes bug fix I could found
Hanada; pgsql-hackers@postgreSQL.org
Subject: Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
A possible compromise that we could perhaps still wedge into 9.5 is to
extend CustomPath with a List of child Paths, and CustomScan with a List
of child Plans, which createplan.c
2015-05-15 8:43 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
Regarding of FDW, as Hanada-san mentioned, I'm uncertain whether
similar feature is also needed because its join-pushdown feature
scan on the result-set of remotely joined relations, thus no need
to have local child Path nodes.
So,
A possible compromise that we could perhaps still wedge into 9.5 is to
extend CustomPath with a List of child Paths, and CustomScan with a List
of child Plans, which createplan.c would know to build from the Paths,
and other modules would then also be aware of these children. I find that
2015-05-12 10:24 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
option-2)
Tom's suggestion. Add a new list field of Path nodes on CustomPath,
then create_customscan_plan() will call static create_plan_recurse()
function to construct child plan nodes.
Probably, the attached patch will be an
Freund'; 'Robert Haas'
Cc: 'Tom Lane'; 'Kohei KaiGai'; 'Thom Brown'; 'Shigeru Hanada';
'pgsql-hackers@postgreSQL.org'
Subject: RE: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
Hi,
Let me back to the original concern and show possible options
we can take here. At least
On Sun, May 10, 2015 at 11:07 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-10 22:51:33 -0400, Robert Haas wrote:
And there's definitely some things
around that pretty much only still exist because changing them would
break too much stuff.
Such as what?
Without even thinking
To: 'Andres Freund'; Robert Haas
Cc: Tom Lane; Kohei KaiGai; Thom Brown; Shigeru Hanada;
pgsql-hackers@postgreSQL.org
Subject: RE: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and
On 2015-05-10 22:51:33 -0400, Robert Haas wrote:
And there's definitely some things
around that pretty much only still exist because changing them would
break too much stuff.
Such as what?
Without even thinking about it:
* linitial vs lfirst vs lnext. That thing still induces an
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and would prefer not to enlarge
Tom,
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function. It means extension
cannot have child node, even if it wants to add a custom-join logic.
Please assume a simple
On Sun, May 10, 2015 at 9:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Your unwillingness to make functions global or to stick PGDLLIMPORT
markings on variables that people want access to is hugely
handicapping extension authors. Many people have
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes.
On 2015-05-10 21:53:45 -0400, Robert Haas wrote:
Please name EVEN ONE instance in which core development has been
prevented for fear of changing a function API.
Even *moving* function declarations to a different file has been laudly
and repeatedly complained about... And there's definitely some
On Sun, May 10, 2015 at 10:37 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-10 21:53:45 -0400, Robert Haas wrote:
Please name EVEN ONE instance in which core development has been
prevented for fear of changing a function API.
Even *moving* function declarations to a different file
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and would prefer not to enlarge
Robert Haas robertmh...@gmail.com writes:
Your unwillingness to make functions global or to stick PGDLLIMPORT
markings on variables that people want access to is hugely
handicapping extension authors. Many people have complained about
that on multiple occasions. Frankly, I find it
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling
On Sat, May 9, 2015 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I originally wanted to go quite the other way with this and check for
join pushdown via handler X any time at least one of the two relations
involved used handler X, even if the other one used some other handler
or was a plain
Robert Haas robertmh...@gmail.com writes:
On Sat, May 9, 2015 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
For these reasons, I think that if an FDW tried to be laxer than tables
must be on the same pg_foreign_server entry to be joined, the odds
approach unity that it would be broken, and
I've committed a cleanup patch along the lines discussed.
One thought is that we could test the nondefault-scan-tuple logic without
a lot of work by modifying the way postgres_fdw deals with columns it
decides don't need to be fetched. Right now it injects NULL columns so
that the remote query
Robert Haas robertmh...@gmail.com writes:
On Fri, May 8, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that we'd really be better off insisting on same server (as in
same pg_foreign_server OID), hence automatically same FDW, and what's
even more important, same user mapping for
2015-05-09 11:21 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Fri, May 8, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was
2015-05-09 8:18 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
2015-05-09 2:46 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
Kouhei Kaigai kai...@ak.jp.nec.com writes:
I've been trying to code-review this patch, because the documentation
seemed several bricks shy of a load, and I find myself entirely
2015-05-09 8:32 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
2015-05-09 3:51 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have
Kouhei Kaigai kai...@ak.jp.nec.com writes:
I've been trying to code-review this patch, because the documentation
seemed several bricks shy of a load, and I find myself entirely confused
by the fdw_ps_tlist and custom_ps_tlist fields.
Main-point of your concern is lack of
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have a
lot of confidence that this stuff is actually in a state where we won't
regret shipping it in 9.5.
Yeah. The POC you were asking for upthread certainly
Robert Haas robertmh...@gmail.com writes:
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have a
lot of confidence that this stuff is actually in a state where we won't
regret shipping it in 9.5.
Yeah. The
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was doing what it's doing. To wit, that the planner
supposes that two foreign tables are potentially remote-joinable if they
share the
On Fri, May 8, 2015 at 2:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, we have two alternatives. I can keep hacking on this and get it
to a state where it seems credible to me, but we won't have any proof
that it actually works (though perhaps we could treat any problems
as bugs that should
On Fri, May 8, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was doing what it's doing. To wit, that the planner
supposes that
2015-05-09 2:46 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
Kouhei Kaigai kai...@ak.jp.nec.com writes:
I've been trying to code-review this patch, because the documentation
seemed several bricks shy of a load, and I find myself entirely confused
by the fdw_ps_tlist and custom_ps_tlist fields.
2015-05-09 3:51 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have a
lot of confidence that this stuff is actually in a state
2015-05-09 6:48 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was doing what it's doing. To wit, that the planner
supposes that two foreign
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I wanted to submit the v14 after the above items get clarified.
The attached patch (v14) includes all what you suggested in the previous
message.
Committed, after heavily
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I wanted to submit the v14 after the above items get clarified.
The attached patch (v14) includes all what you suggested in the previous
message.
Committed, after
On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I wanted to submit the v14 after the above items get clarified.
The attached patch (v14) includes all what you suggested in the previous
message.
Committed, after heavily working over the documentation, and with some
On Sun, Apr 26, 2015 at 10:00 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The attached patch v13 is revised one according to the suggestion
by Robert.
Thanks.
The last hunk in foreign.c is a useless whitespace change.
Sorry, my oversight.
+ /* actually, not shift members */
On Thu, Apr 30, 2015 at 9:16 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
It seems to me the code block for T_ForeignScan and T_CustomScan in
setrefs.c are a bit large. It may be better to have a separate
function like T_IndexOnlyScan.
How about your opinion?
Either way is OK with me.
On Thu, Apr 30, 2015 at 9:16 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
It seems to me the code block for T_ForeignScan and T_CustomScan in
setrefs.c are a bit large. It may be better to have a separate
function like T_IndexOnlyScan.
How about your opinion?
Either way is OK with me.
On Fri, Apr 24, 2015 at 3:08 PM, Shigeru HANADA shigeru.han...@gmail.com
wrote:
Hi Ashutosh,
Thanks for the review.
2015/04/22 19:28、Ashutosh Bapat ashutosh.ba...@enterprisedb.com のメール：
Tests
---
1.The postgres_fdw test is re/setting enable_mergejoin at various
places. The goal of
On Mon, Apr 27, 2015 at 5:05 AM, Shigeru HANADA
shigeru.han...@gmail.com wrote:
Currently INNER JOINs with unsafe join conditions are not pushed down, so
such test is not in the suit. As you say, in theory, INNER JOINs can be
pushed down even they have push-down-unsafe join conditions,
On Sun, Apr 26, 2015 at 10:00 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The attached patch v13 is revised one according to the suggestion
by Robert.
Thanks.
The last hunk in foreign.c is a useless whitespace change.
+ /* actually, not shift members */
Change to: shift of 0 is the
Hi Ashutosh,
Thanks for the review.
2015/04/22 19:28、Ashutosh Bapat ashutosh.ba...@enterprisedb.com のメール：
Tests
---
1.The postgres_fdw test is re/setting enable_mergejoin at various places. The
goal of these tests seems to be to test the sanity of foreign plans
generated. So, it might
, 2015 11:23 PM
To: 'Robert Haas'
Cc: Tom Lane; Thom Brown; Shigeru Hanada; pgsql-hackers@postgreSQL.org
Subject: Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
On Wed, Apr 22, 2015 at 10:48 PM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
+ else if (scan-scanrelid
Hi Ashutosh,
Thanks for the review.
2015/04/22 19:28、Ashutosh Bapat ashutosh.ba...@enterprisedb.com のメール：
Tests
---
1.The postgres_fdw test is re/setting enable_mergejoin at various places. The
goal of these tests seems to be to test the sanity of foreign plans
generated. So, it might
On Wed, Apr 22, 2015 at 10:48 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
+ else if (scan-scanrelid == 0
+(IsA(scan, ForeignScan) || IsA(scan, CustomScan)))
+ varno = INDEX_VAR;
Suppose scan-scanrelid == 0 but the scan type is something else? Is
On Wed, Apr 22, 2015 at 10:48 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
+ else if (scan-scanrelid == 0
+(IsA(scan, ForeignScan) || IsA(scan, CustomScan)))
+ varno = INDEX_VAR;
Suppose scan-scanrelid == 0 but the scan type is something
On Tue, Apr 21, 2015 at 10:33 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
[ new patch ]
A little more nitpicking:
ExecInitForeignScan() and ExecInitCustomScan() could declare
currentRelation inside the if (scanrelid 0) block instead of in the
outer scope.
I'm not too excited about the
On Wed, Mar 25, 2015 at 9:51 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The attached patch adds GetForeignJoinPaths call on make_join_rel() only when
'joinrel' is actually built and both of child relations are managed by same
FDW driver, prior to any other built-in join paths.
I adjusted
On Fri, Mar 13, 2015 at 8:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 13, 2015 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't object to the concept, but I think that is a pretty bad place
to put the hook call: add_paths_to_joinrel is
Hi Robert,
Thanks for your comments.
A few random cosmetic problems:
- The hunk in allpaths.c is useless.
- The first hunk in fdwapi.h contains an extra space before the
closing parenthesis.
OK, it's my oversight.
And then:
+ else if (scan-scanrelid == 0
+
Kaigai-san,
I reviewed the Custom/Foreign join API patch again after writing a patch of
join push-down support for postgres_fdw.
2015/03/26 10:51、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
building (or searching from a
: Shigeru HANADA [mailto:shigeru.han...@gmail.com]
Sent: Friday, April 17, 2015 1:44 PM
To: Kaigai Kouhei(海外 浩平)
Cc: Ashutosh Bapat; Robert Haas; Tom Lane; Thom Brown;
pgsql-hackers@postgreSQL.org
Subject: ##freemail## Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5]
Custom
Plan API)
Kaigai-san
-APIs (Re: [HACKERS] [v9.5]
Custom
Plan API)
Kaigai-san,
2015/04/15 22:33、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
Oops, that’s right. Attached is the revised version. I chose fully
qualified
name, schema.relname [alias] for the output. It would waste some cycles
during
planning
Of Shigeru HANADA
Sent: Tuesday, April 14, 2015 7:49 PM
To: Kaigai Kouhei(海外 浩平)
Cc: Ashutosh Bapat; Robert Haas; Tom Lane; Thom Brown;
pgsql-hackers@postgreSQL.org
Subject: Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
KaiGai-san,
2015/04/14 14:04、Kouhei Kaigai kai
KaiGai-san,
2015/04/14 14:04、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
* Fix typos
Please review the v11 patch, and mark it as “ready for committer” if it’s ok.
It's OK for me, and wants to be reviewed by other people to get it committed.
Thanks!
In addition to essential features, I
Hanada-san,
Thanks for further review, but I found two bugs in v10 patch.
I’ve fixed them and wrapped up v11 patch here.
* Fix bug about illegal column order
Scan against a base relation returns columns in order of column definition,
but
its target list might require different order.
2015/04/09 10:48、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
* merge_fpinfo()
It seems to me fpinfo-rows should be joinrel-rows, and
fpinfo-width also should be joinrel-width.
No need to have special intelligence here, isn't it?
Oops. They are vestige of my struggle which disabled
Hanada-san,
In addition to your comments, I removed useless code that retrieves
ForeignPath
from outer/inner RelOptInfo and store them into ForeignPath#fdw_private. Now
postgres_fdw’s join pushd-down is free from existence of ForeignPath under the
join relation. This means that we can
-hackers-ow...@postgresql.org] On Behalf Of Shigeru Hanada
Sent: Friday, April 03, 2015 7:32 PM
To: Kaigai Kouhei(海外 浩平)
Cc: Ashutosh Bapat; Robert Haas; Tom Lane; Thom Brown;
pgsql-hackers@postgreSQL.org
Subject: Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
Attached
2015/03/25 12:59、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
At this moment, I'm not 100% certain about its logic. Especially, I didn't
test SEMI- and ANTI- join cases yet.
However, time is money - I want people to check overall design first, rather
than detailed debugging. Please tell me if I
On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA shigeru.han...@gmail.com
wrote:
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for
just building (or searching from a list) a RelOptInfo for given relids.
After that make_join_rel() calls add_paths_to_joinrel() with
On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA shigeru.han...@gmail.com
wrote:
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for
just building (or searching from a list) a RelOptInfo for given relids. After
that make_join_rel() calls add_paths_to_joinrel() with
2015/03/25 19:09、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA shigeru.han...@gmail.com
wrote:
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for
just building (or searching from a list) a RelOptInfo for given relids.
2015/03/25 12:59、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
At this moment, I'm not 100% certain about its logic. Especially, I didn't
test SEMI- and ANTI- join cases yet.
However, time is money - I want people to check overall design first,
rather
than detailed debugging. Please tell
2015/03/25 19:47、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
The reason why FDW handler was called multiple times on your example is,
your modified make_join_rel() does not check whether build_join_rel()
actually build a new RelOptInfo, or just a cache reference, doesn't it?
Yep. After
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
building (or searching from a list) a RelOptInfo for given relids. After that
make_join_rel() calls add_paths_to_joinrel() with appropriate arguments per
join
type to generate actual Paths implements the join.
2015/03/25 18:53、Ashutosh Bapat ashutosh.ba...@enterprisedb.com のメール：
On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA shigeru.han...@gmail.com
wrote:
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
building (or searching from a list) a RelOptInfo for given
2015/03/25 19:47、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
The reason why FDW handler was called multiple times on your example is,
your modified make_join_rel() does not check whether build_join_rel()
actually build a new RelOptInfo, or just a cache reference, doesn't it?
Yep. After that
2015/03/25 19:09、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA shigeru.han...@gmail.com
wrote:
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for
just building (or searching from a list) a RelOptInfo for given relids.
2015/03/26 10:51、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
The attached patch adds GetForeignJoinPaths call on make_join_rel() only when
'joinrel' is actually built and both of child relations are managed by same
FDW driver, prior to any other built-in join paths.
I adjusted the hook
2015/03/23 9:12、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
Sorry for my response late. It was not easy to code during business trip.
The attached patch adds a hook for FDW/CSP to replace entire join-subtree
by a foreign/custom-scan, according to the discussion upthread.
GetForeignJoinPaths
)
Cc: Robert Haas; Tom Lane; Ashutosh Bapat; Thom Brown;
pgsql-hackers@postgreSQL.org
Subject: Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
2015/03/23 9:12、Kouhei Kaigai kai...@ak.jp.nec.com のメール：
Sorry for my response late. It was not easy to code during business trip
On Wed, Mar 18, 2015 at 9:33 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
So, overall consensus for the FDW hook location is just before the
set_chepest()
at standard_join_search() and merge_clump(), isn't
On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
So, overall consensus for the FDW hook location is just before the
set_chepest()
at standard_join_search() and merge_clump(), isn't it?
Yes, I think so.
Let me make a design of FDW hook to reduce code duplications
On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
So, overall consensus for the FDW hook location is just before the
set_chepest()
at standard_join_search() and merge_clump(), isn't it?
Yes, I think so.
Let me make a design of FDW hook to reduce code
On Wed, Mar 18, 2015 at 9:33 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
So, overall consensus for the FDW hook location is just before the
set_chepest()
at standard_join_search() and merge_clump(), isn't it?
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
It might be an idea if foreign-scan path is not wiped out regardless of the
estimated cost, we will be able to construct an entirely remote-join path
even if
On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
A way to work around this is to leave the ForeignPaths (there can possibly be
only one foreign path per join relation) in the joinrel without removing
them.
FDW should work on joining two relations if they have
On Tue, Mar 17, 2015 at 8:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
A way to work around this is to leave the ForeignPaths (there can
possibly be
only one foreign path per join relation) in the joinrel
On 2015/03/14 7:18, Robert Haas wrote:
I think the foreign data wrapper join pushdown case, which also aims
to substitute a scan for a join, is interesting to think about, even
though it's likely to be handled by a new FDW method instead of via
the hook. Where should the FDW method get called
-Original Message-
From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
Sent: Monday, March 16, 2015 9:59 PM
To: Robert Haas
Cc: Tom Lane; Thom Brown; Kaigai Kouhei(海外 浩平); pgsql-hackers@postgreSQL.org
Subject: ##freemail## Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5
On Tue, Mar 17, 2015 at 10:28 AM, Shigeru Hanada shigeru.han...@gmail.com
wrote:
2015-03-14 7:18 GMT+09:00 Robert Haas robertmh...@gmail.com:
I think the foreign data wrapper join pushdown case, which also aims
to substitute a scan for a join, is interesting to think about, even
though
On Sat, Mar 14, 2015 at 3:48 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 13, 2015 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another bit of this that I think we could commit without fretting
about it too much is the code adding
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
It might be an idea if foreign-scan path is not wiped out regardless of the
estimated cost, we will be able to construct an entirely remote-join path
even if intermediation
1 - 100 of 271 matches
Mail list logo
