Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
От | Ashutosh Bapat |
---|---|
Тема | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |
Дата | |
Msg-id | CAFjFpRdGFLrs9NyfrBSyX90cWuxrfD6PYPTxwv9rURBg4hk9=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: postgres_fdw join pushdown (was Re:
Custom/Foreign-Join-APIs)
|
Список | pgsql-hackers |
On Thu, Feb 4, 2016 at 3:28 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
-- On 2016/02/04 17:58, Etsuro Fujita wrote:On 2016/02/04 8:00, Robert Haas wrote:On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas <robertmhaas@gmail.com>
wrote:On Wed, Feb 3, 2016 at 12:08 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:PFA patches with naming conventions similar to previous ones.
pg_fdw_core_v7.patch: core changes
pg_fdw_join_v7.patch: postgres_fdw changes for join pushdown
pg_join_pd_v7.patch: combined patch for ease of testing.
One more: I think the following in postgresGetForeignJoinPaths() is a good idea, but I think it's okay to just check whether root->rowMarks is non-NIL, because that since we have rowmarks for all base relations except the target, if we have root->parse->commandType==CMD_DELETE (or root->parse->commandType==CMD_UPDATE), then there would be at least one non-target base relation in the joinrel, which would have a rowmark.
Sorry, I am unable to understand it fully. But what you are suggesting that if there are root->rowMarks, then we are sure that there is at least one base relation apart from the target, which needs locking rows. Even if we don't have one, still changes in a row of target relation after it was scanned, can result in firing EPQ check, which would need the local plan to be executed, thus even if root->rowMarks is NIL, EPQ check can fire and we will need alternate local plan.
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: