On 03.12.2011 01:05, Tom Lane wrote:
Heikki Linnakangas 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 dep
Heikki Linnakangas 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 depending on whether you prefer
On 03.12.2011 00:24, Tom Lane wrote:
Heikki Linnakangas 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 tim
Heikki Linnakangas 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 time, because of different output
On 02.12.2011 18:55, Tom Lane wrote:
Heikki Linnakangas 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 another
Heikki Linnakangas 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 another relation.
I think this is f
On 17.11.2011 17:24, Tom Lane wrote:
Heikki Linnakangas 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 sh
Heikki Linnakangas 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 should certainly not "throw away
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
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
Robert Haas 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 core, but the onl
2011/10/10 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.
(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
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 co
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 priorit
2011年10月4日12:08 Shigeru Hanada :
>> 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, so in my desig
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
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 (ena
2011/9/21 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
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
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
201
21 matches
Mail list logo
