Re: WIP: Join push-down for foreign tables - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: WIP: Join push-down for foreign tables
Date
Msg-id A42BE4E5-4606-4A32-A11D-12C8E9C882B1@phlo.org
Whole thread Raw
In response to Re: WIP: Join push-down for foreign tables  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
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 correct. However, the planner gives
> higher priority on the join plan between
> local and foreign than pushing-down foreign relations.

The textbook approach to that is to factor the cost of transferring the
rows over the network into the plan costs. That, of course, only works
once we have statistics for the foreign tables. But AFAIK we eventually
want to have those, so I'd say punt this until that time.

> Does it make sense not to consider any other possible plans when FDW
> decided a particular join can be
> pushed down?

I think in the long run we're going to want a cost-based decision there.
Pushing down a join is only a win if the join selectivity is low. For a
selectivity close to 1.0, it may very well be many times more efficient
to fetch the tables separately and join them locally. You'll be fetching
only |A| + |B| rows for a local join, instead of |A| * |B| rows for a remote
join (assuming A,B are tables with cardinality |A|, |B|).

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Next
From: Greg Stark
Date:
Subject: Re: alter table only ... drop constraint broken in HEAD