Re: Performance improvement for joins where outer side is unique
От | Tom Lane |
---|---|
Тема | Re: Performance improvement for joins where outer side is unique |
Дата | |
Msg-id | 29063.1457803951@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance improvement for joins where outer side is unique (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > The new join pushdown code in postgres_fdw does not grok SEMI and ANTI > joins because there is no straightforward way of reducing those back > to SQL. They can originate in multiple ways and not all of those can > be represented easily. I think it would be nice to do something to > fix this. For example, if a LEFT join WHERE outer_column IS NULL > turns into an ANTI join, it would be nice if that were marked in some > way so that postgres_fdw could conveniently emit it in the original > form. > Maybe the people who have been working on that patch just haven't been > creative enough in thinking about how to solve this problem, but it > makes me greet the idea of more join types that don't map directly > back to SQL with somewhat mixed feelings. I can't summon a whole lot of sympathy for that objection. These cases won't arise with postgres_fdw as it stands because we'd never be able to prove uniqueness on a foreign table. When and if someone tries to improve that, we can think about how the whole thing ought to map to FDWs. Having said that, your point does add a bit of weight to David's suggestion of inventing two new join-type codes rather than overloading JOIN_SEMI. I'd still be a bit inclined to display JOIN_INNER_UNIQUE or whatever we call it as a "Semi" join in EXPLAIN, though, just to minimize the amount of newness there. regards, tom lane
В списке pgsql-hackers по дате отправления: