Skip site navigation (1) Skip section navigation (2)

Re: FDW for PostgreSQL

From: "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: "'Shigeru HANADA'" <shigeru(dot)hanada(at)gmail(dot)com>, "'Kohei KaiGai'" <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FDW for PostgreSQL
Date: 2012-10-11 09:10:58
Message-ID: 003001cda790$53b989d0$fb2c9d70$@lab.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi Hanada-san,

> Please examine attached v2 patch (note that is should be applied onto
> latest dblink_fdw_validator patch).

I've reviewed your patch quickly.  I noticed that the patch has been created in
a slightly different way from the guidelines:
http://www.postgresql.org/docs/devel/static/fdw-planning.html  The guidelines
say the following, but the patch identifies the clauses in
baserel->baserestrictinfo in GetForeignRelSize, not GetForeignPaths.  Also, it
has been implemented so that most sub_expressions are evaluated at the remote
end, not the local end, though I'm missing something.  For postgresql_fdw to be
a good reference for FDW developers, ISTM it would be better that it be
consistent with the guidelines.  I think it would be needed to update the
following document or redesign the function to be consistent with the following
document.

    As an example, the FDW might identify some restriction clauses of the form
foreign_variable= sub_expression, which it determines can be executed on the
remote server given the locally-evaluated value of the sub_expression. The
actual identification of such a clause should happen during GetForeignPaths,
since it would affect the cost estimate for the path.

Thanks,

Best regards,
Etsuro Fujita



In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2012-10-11 09:19:34
Subject: Re: replace plugins directory with GUC
Previous:From: Simon RiggsDate: 2012-10-11 08:57:28
Subject: Re: change in LOCK behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group