Re: [HACKERS] WIP: Join push-down for foreign tables

2012-01-05 Thread Heikki Linnakangas
On 03.12.2011 01:05, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: Hmm, so you're saying that the FDW function needs to be able to return multiple paths for a single joinrel. Fair enough, and that's not specific to remote joins. Even a single-table foreign scan

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-12-02 Thread Heikki Linnakangas
On 17.11.2011 17:24, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: When the FDW recognizes it's being asked to join a ForeignJoinPath and a ForeignPath, or two ForeignJoinPaths, it throws away the old SQL it constructed to do the two-way join, and builds a new

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-12-02 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Tom, what do you think of this part? I think it would be a lot more natural API if the planner could directly ask the FDW to construct a plan for a three (or more)-way join, instead of asking it to join a join relation into

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-12-02 Thread Heikki Linnakangas
On 02.12.2011 18:55, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: Tom, what do you think of this part? I think it would be a lot more natural API if the planner could directly ask the FDW to construct a plan for a three (or more)-way join, instead of asking it

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-12-02 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 02.12.2011 18:55, Tom Lane wrote: Furthermore, you seem to be imagining that there is only one best path for any join, which isn't the case. No, I understand that the planner considers many alternatives, even at the same

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-12-02 Thread Heikki Linnakangas
On 03.12.2011 00:24, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: On 02.12.2011 18:55, Tom Lane wrote: Furthermore, you seem to be imagining that there is only one best path for any join, which isn't the case. No, I understand that the planner considers

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-12-02 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Hmm, so you're saying that the FDW function needs to be able to return multiple paths for a single joinrel. Fair enough, and that's not specific to remote joins. Even a single-table foreign scan could be implemented differently

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-11-17 Thread Heikki Linnakangas
On 15.11.2011 19:16, Shigeru Hanada wrote: This is the second effort for $SUBJECT. Attached patch requires pgsql_fdw patches[1] to be applied previously. This patch provides: * Changes for backend * Add new planner node ForeignJoinPath and related routines. In current design, planner

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-11-17 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: When the FDW recognizes it's being asked to join a ForeignJoinPath and a ForeignPath, or two ForeignJoinPaths, it throws away the old SQL it constructed to do the two-way join, and builds a new one to join all three tables. It

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-21 Thread Kohei KaiGai
How about the current status of this patch, although it is still Waiting on author. If Hanada-san would propose contrib/pgsql_fdw as a basis of join-pushdown feature, I'll likely volunteer to review the patch. I'm also interested in this feature. Hopefully, I'd like to try other kind of pushing

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-10 Thread Shigeru Hanada
(2011/10/08 1:06), Kohei KaiGai wrote: What is the reason why the foreign join is not pushed down? Maybe, injected Sort plan prevent the planner to consider both side of relations being foreign scan owned by same server? I'm still investigating the reason. Thanks for your testing. I'm not

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-10 Thread Robert Haas
2011/10/10 Shigeru Hanada shigeru.han...@gmail.com: (2011/10/08 1:06), Kohei KaiGai wrote: What is the reason why the foreign join is not pushed down? Maybe, injected Sort plan prevent the planner to consider both side of relations being foreign scan owned by same server? I'm still

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-10 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: This might be out of left field, but wouldn't it make more sense to get postgresql_fdw committed first, and then add the join push-down functionality afterwards? I mean, otherwise, we're going to be left with a situation where we have join pushdown in

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-09 Thread Kohei KaiGai
Hanada-san, The proposed patch put an invocation of PlanForeignJoin on the create_foreignjoin_path() being also called by match_unsorted_outer(). Is it a suitable position to make a decision whether a join can be pushed-down? I think; it needs an additional functionality to provide higher

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-09 Thread Florian Pflug
On Oct9, 2011, at 13:35 , Kohei KaiGai wrote: I think; it needs an additional functionality to provide higher priority on the foreign-join plan that other plans, when fdw determind a particular join can be pushed-down. (Sorry, I have no idea right now.) Probably, the basic design is

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-07 Thread Kohei KaiGai
2011年10月4日12:08 Shigeru Hanada shigeru.han...@gmail.com: In my opinion, FdwRoutine should have an additional API to inform the core its supported features; such as inner-join, outer-join, order-by, group-by, aggregate functions, insert, update, delete, etc... in the future version. Sure,

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-04 Thread Shigeru Hanada
Kaigai-san, Thanks for the review. (2011/10/03 17:07), Kohei KaiGai wrote: At first, I tried to use file_fdw, however, it was crashed of course. It seems to me this logic should be modified to confirm whether the target FDW support join push down, or not. + if (enable_foreignjoin +

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-10-03 Thread Kohei KaiGai
Hanada-san, I applied your patch and run a few test cases. while this test, I noticed a few points. At first, I tried to use file_fdw, however, it was crashed of course. It seems to me this logic should be modified to confirm whether the target FDW support join push down, or not. + if

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-09-21 Thread Shigeru Hanada
Hi Michael, (2011/09/21 12:52), Michael Paquier wrote: I am interested in the development you are doing regarding join push down and fdw stuff for remote postgreSQL servers. Is there a way to get the postgres fdw you are providing here for common 9.1? I saw that the tar you are providing

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-09-21 Thread Michael Paquier
2011/9/21 Shigeru Hanada shigeru.han...@gmail.com Hi Michael, (2011/09/21 12:52), Michael Paquier wrote: I am interested in the development you are doing regarding join push down and fdw stuff for remote postgreSQL servers. Is there a way to get the postgres fdw you are providing here

Re: [HACKERS] WIP: Join push-down for foreign tables

2011-09-20 Thread Michael Paquier
Hi, I am interested in the development you are doing regarding join push down and fdw stuff for remote postgreSQL servers. Is there a way to get the postgres fdw you are providing here for common 9.1? I saw that the tar you are providing here is adapted only for your patch. Regards, Michael