Hi all,
(2012/03/07 3:39), Tom Lane wrote:
> A bigger issue with postgresql_fdw_validator is that it supposes that
> the core backend is authoritative as to what options libpq supports,
> which is bad design on its face. It would be much more sensible for
> dblink to be asking libpq what options
2012/4/9 Shigeru HANADA :
> 1) connect to the server at the beginning of the local query
> 2) execute EXPLAIN for foreign table foo
> 3) execute EXPLAIN for foreign table bar
> 4) execute actual query for foreign table foo
> 5) execute actual query for foreign table bar
> 6) disco
This is Gerald Devotta, Recruitment Specialist with Newt Global LLC, a
global staffing solutions provider that has been serving the
telecommunications and utility industries.
I am contacting you to let you know that your resume came to my attention
while I was conducting a job search for a pro
(2012/04/08 5:19), Thom Brown wrote:
> 2012/4/7 Shigeru HANADA:
>> I've updated pgsql_fdw so that it can collect statistics from foreign
>> data with new FDW API.
>
> I notice that if you restart the remote server, the connection is
> broken, but the client doesn't notice this until it goes to fir
2012/4/7 Shigeru HANADA :
> I've updated pgsql_fdw so that it can collect statistics from foreign
> data with new FDW API.
I notice that if you restart the remote server, the connection is
broken, but the client doesn't notice this until it goes to fire off
another command. Should there be an opt
Shigeru Hanada writes:
> On Fri, Apr 6, 2012 at 11:20 PM, Tom Lane wrote:
>> In
>> particular I do not like the specific way it's done in the v7 patch
>> (I've not looked at v8 yet) because the interposed logic has a
>> hard-wired assumption that foreign tables do not have inheritance
>> children
On Fri, Apr 6, 2012 at 11:20 PM, Tom Lane wrote:
>> Another concern is the place where we hook the process of ANALYZE. IOW,
>> how much portion of ANALYZE should be overridable?
>
> Not much, IMO. The FDW should be able to decide whether or not to
> analyze a particular table, and it should be i
Shigeru HANADA writes:
> (2012/04/06 1:29), Tom Lane wrote:
>> The one thing that seems pretty clear from this discussion is that one
>> size doesn't fit all. I think we really ought to provide a hook so that
>> the FDW can determine whether ANALYZE applies to its foreign tables at
>> all, and ho
Excuse me for cutting in,
2012/4/6 Shigeru HANADA :
> To support foreign-table ANALYZE by adding a new hook, we would need a
> mechanism (or at least documented guide lines) to manage the chain of
> hook functions, because such hook might be used by multiple FDWs (or
> other plug-ins) at the same
(2012/04/06 1:29), Tom Lane wrote:
> "Albe Laurenz" writes:
>> Maybe the FDW API could be extended so that foreign data wrappers
>> can provide a random sample to avoid a full table scan.
>
> The one thing that seems pretty clear from this discussion is that one
> size doesn't fit all. I think w
"Albe Laurenz" writes:
> I think that the price of a remote table scan is something
> we should be willing to pay for good local statistics.
> And there is always the option not to analyze the foreign
> table if you are not willing to pay that price.
> Maybe the FDW API could be extended so that
day, April 05, 2012 9:36 PM
To: Shigeru HANADA; Albe Laurenz
Cc: Tom Lane; Kevin Grittner; Robert Haas; PostgreSQL-development; Kohei
KaiGai; Martijn van Oosterhout; Hitoshi Harada
Subject: Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server
At 22:11 12/03/28 +0900, Shigeru HANADA wrote:
>ANALYZ
At 22:11 12/03/28 +0900, Shigeru HANADA wrote:
ANALYZE support for foreign tables is proposed by Fujita-san in current
CF, so I'd like to push it.
I updated the patch to the latest HEAD. Please find attached a patch.
Best regards,
Etsuro Fujita
postgresql-analyze-v7.patch
Description: Binar
Shigeru HANADA wrote:
>> During a foreign scan, type input functions are used to convert
>> the text representation of values. If a foreign table is
misconfigured,
>> you can get error messages from these functions, like:
>>
>> ERROR: invalid input syntax for type double precision: "etwas"
>> or
Shigeru HANADA wrote:
> Attached are latest version of pgsql_fdw patches. Note that
> pgsql_fdw_analyze.patch is only for test the effect of local
statistics.
> Please apply patches in the order below:
>
> (1) pgsql_fdw_v18.patch
> (2) pgsql_fdw_pushdown_v11.patch
> (3) pgsql_fdw_analyze.patch (
I wrote:
>> Changes from previous version
>> =
>>
>> 1) Don't use remote EXPLAIN for cost/rows estimation, so now planner
>> estimates result rows and costs on the basis of local statistics such
>> as pg_class and pg_statistic. To update local statistics, I added
>> pgs
I wrote:
>> How about getting # of rows estimate by executing EXPLAIN for
>> fully-fledged remote query (IOW, contains pushed-down WHERE clause),
and
>> estimate selectivity of local filter on the basis of the statistics
>> which are generated by FDW via do_analyze_rel() and FDW-specific
>> samplin
(2012/03/28 21:07), Albe Laurenz wrote:
> I found another limitation of this approach:
> pgsql_fdw_analyze() has to run as a user who can update
> pg_statistic, and this user needs a user mapping to a remote
> user who can read pg_statistic.
>
> This is not necessary for normal operation and needs
(2012/03/28 16:18), Albe Laurenz wrote:
> I wrote:
>>> How about getting # of rows estimate by executing EXPLAIN for
>>> fully-fledged remote query (IOW, contains pushed-down WHERE clause),
> and
>>> estimate selectivity of local filter on the basis of the statistics
>>> which are generated by FDW
On 28 March 2012 08:39, Thom Brown wrote:
> On 28 March 2012 08:13, Thom Brown wrote:
>> 2012/3/28 Shigeru HANADA :
>>> (2012/03/27 20:32), Thom Brown wrote:
2012/3/26 Shigeru HANADA:
> * pgsql_fdw_v17.patch
> - Adds pgsql_fdw as contrib module
> * pgsql_fdw_pushdown_v10.patc
On 28 March 2012 08:13, Thom Brown wrote:
> 2012/3/28 Shigeru HANADA :
>> (2012/03/27 20:32), Thom Brown wrote:
>>> 2012/3/26 Shigeru HANADA:
* pgsql_fdw_v17.patch
- Adds pgsql_fdw as contrib module
* pgsql_fdw_pushdown_v10.patch
- Adds WHERE push down capability to pgs
2012/3/28 Shigeru HANADA :
> (2012/03/27 20:32), Thom Brown wrote:
>> 2012/3/26 Shigeru HANADA:
>>> * pgsql_fdw_v17.patch
>>> - Adds pgsql_fdw as contrib module
>>> * pgsql_fdw_pushdown_v10.patch
>>> - Adds WHERE push down capability to pgsql_fdw
>>> * pgsql_fdw_analyze_v1.patch
>>> - A
(2012/03/27 20:32), Thom Brown wrote:
> 2012/3/26 Shigeru HANADA:
>> * pgsql_fdw_v17.patch
>> - Adds pgsql_fdw as contrib module
>> * pgsql_fdw_pushdown_v10.patch
>> - Adds WHERE push down capability to pgsql_fdw
>> * pgsql_fdw_analyze_v1.patch
>> - Adds pgsql_fdw_analyze function for u
Shigeru HANADA wrote:
>> My gut feeling is that planning should be done by the server which
>> will execute the query.
>
> Agreed, if selectivity of both local filtering and remote filtering
were
> available, we can estimate result rows correctly and choose better
plan.
>
> How about getting # of
2012/3/26 Shigeru HANADA :
> (2012/03/15 23:06), Shigeru HANADA wrote:
>> Although the patches are still WIP, especially in WHERE push-down part,
>> but I'd like to post them so that I can get feedback of the design as
>> soon as possible.
>
> I've implemented pgsql_fdw's own deparser and enhanced
Thanks for the comments.
(2012/03/27 18:36), Albe Laurenz wrote:
>> 2) Defer planning stuffs as long as possible to clarify the role of
> each
>> function. Currently GetRelSize just estimates result rows from local
>> statistics, and GetPaths adds only one path which represents SeqScan
> on
>> re
Shigeru HANADA wrote:
> I've implemented pgsql_fdw's own deparser and enhanced some features
> since last post. Please apply attached patches in the order below:
> Changes from previous version
> =
>
> 1) Don't use remote EXPLAIN for cost/rows estimation, so now plann
Tom Lane wrote:
> Shigeru Hanada writes:
>> Thanks for the review. Agreed to write own depraser for pgsql_fdw
>> which handles nodes which can be pushed down. Every SQL-based FDW
>> which constructs SQL statement for each local query would need such
>> module inside.
>
> Yeah. That's kind of a
(2012/03/12 13:04), Etsuro Fujita wrote:
> (2012/03/09 23:48), Tom Lane wrote:
>> Etsuro Fujita writes:
>>> 2. IMHO RelOptInfo.fdw_private seems confusing. How about renaming it
>>> to e.g., RelOptInfo.fdw_state?
>>
>> Why is that better? It seems just as open to confusion with another
>> fiel
(2012/03/09 23:48), Tom Lane wrote:
> Etsuro Fujita writes:
Thank you for your answer.
>> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant.
>>Why not use RelOptInfo.pages and RelOptInfo.tuples?
>
> I intentionally avoided setting RelOptInfo.pages because that would hav
On Sat, Mar 10, 2012 at 11:38:51AM -0500, Tom Lane wrote:
> Shigeru Hanada writes:
> > Thanks for the review. Agreed to write own depraser for pgsql_fdw
> > which handles nodes which can be pushed down. Every SQL-based FDW
> > which constructs SQL statement for each local query would need such
>
Shigeru Hanada writes:
> Thanks for the review. Agreed to write own depraser for pgsql_fdw
> which handles nodes which can be pushed down. Every SQL-based FDW
> which constructs SQL statement for each local query would need such
> module inside.
Yeah. That's kind of annoying, and the first thi
Shigeru Hanada writes:
> I've not read whole of the patch yet, but I have basic questions.
> 1) IIUC, GetForeignRelSize should set baserel->rows to the number of
> rows the ForeignScan node returns to upper node, but not the number
> of rows FDW returns to core executor, right?
It should be the
(2012/03/06 23:47), Albe Laurenz wrote:
> Shigeru Hanada wrote:
>> Connection should be closed only when the trigger is a
>> top level transaction and it's aborting, but isTopLevel flag was not
>> checked. I fixed the bug and added regression tests for such cases.
>
> I wondered ab
(2012/03/09 1:18), Tom Lane wrote:
> I've been looking at this patch a little bit over the past day or so.
> I'm pretty unhappy with deparse.c --- it seems like a real kluge,
> inefficient and full of corner-case bugs. After some thought I believe
> that you're ultimately going to have to abandon
I've not read whole of the patch yet, but I have basic questions.
1) IIUC, GetForeignRelSize should set baserel->rows to the number of
rows the ForeignScan node returns to upper node, but not the number
of rows FDW returns to core executor, right?
BTW, once Fujita-san's ANALYZE support patch is m
Etsuro Fujita writes:
> (2012/03/09 14:00), Tom Lane wrote:
>> Attached is a draft patch for that.
> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant.
> Why not use RelOptInfo.pages and RelOptInfo.tuples?
I intentionally avoided setting RelOptInfo.pages because that woul
(2012/03/09 14:00), Tom Lane wrote:
I wrote:
There are a couple of other points that make me think we need to revisit
the PlanForeignScan API definition some more, too. ...
So we need to break down what PlanForeignScan currently does into three
separate steps. The first idea that comes to mind
I wrote:
> There are a couple of other points that make me think we need to revisit
> the PlanForeignScan API definition some more, too. ...
> So we need to break down what PlanForeignScan currently does into three
> separate steps. The first idea that comes to mind is to call them
> GetForeignRe
Shigeru Hanada writes:
> [ pgsql_fdw_v15.patch ]
I've been looking at this patch a little bit over the past day or so.
I'm pretty unhappy with deparse.c --- it seems like a real kluge,
inefficient and full of corner-case bugs. After some thought I believe
that you're ultimately going to have to
Shigeru Hanada writes:
> Agreed. Attached fdw_helper patch doesn't contain GetFdwOptionValue()
> any more, and pgsql_fdw patch accesses only necessary catalogs.
I've committed the fdw_helper part of this, with some very minor
improvements.
regards, tom lane
--
Sent via
On tis, 2012-03-06 at 13:39 -0500, Tom Lane wrote:
> A bigger issue with postgresql_fdw_validator is that it supposes that
> the core backend is authoritative as to what options libpq supports,
> which is bad design on its face. It would be much more sensible for
> dblink to be asking libpq what o
Shigeru Hanada writes:
> Attached patches also contains changes to catch up to the redesign of
> PlanForeignScan.
I started to look at this patch, which soon led me back to the
prerequisite patch fdw_helper_v5.patch (that is the last version you
posted of that one, right?). I can see the value o
Peter Eisentraut writes:
> On tor, 2012-03-01 at 20:56 +0900, Shigeru Hanada wrote:
>> How about moving postgresql_fdw_validator into dblink,
> That's probably a good move. If this were C++, we might try to subclass
> this whole thing a bit, to avoid code duplication, but I don't see an
> easy w
Shigeru Hanada wrote:
>Connection should be closed only when the trigger is a
> top level transaction and it's aborting, but isTopLevel flag was not
> checked. I fixed the bug and added regression tests for such cases.
I wondered about that - is it really necessary to close the re
(2012/03/06 6:19), Tom Lane wrote:
> I've committed the PlanForeignScan API change, with that change and
> some other minor editorialization. The pgsql_fdw patch now needs an
> update, so I set it back to Waiting On Author state.
Thanks.
I've revised pgsql_fdw to catch up to this change, but I'l
Shigeru Hanada wrote:
[pgsql_fdw_v12.patch]
I know this is not the latest version, but I played around with it and
tickled a bug.
It seems to have a problem with rolled back subtransactions.
test=> \d+ remote
Foreign table "laurenz.remote"
Column | Type | Modifiers |
I wrote:
> I'm inclined to think that if we provide this function in core at all,
> it should take a parameter list long enough to let it fill in the Path
> completely. That would imply that any future changes in Path structs
> would result in a change in the parameter list, which would break
> ca
Shigeru Hanada writes:
> So, just renaming create_foreignscan_path to plural form seems missing
> the point.
I agree that that wouldn't be an improvement. What bothers me about the
patch's version of this function is that it just creates a content-free
Path node and leaves it to the caller to fi
(2012/03/05 21:05), Etsuro Fujita wrote:
> (2012/03/05 21:00), Etsuro Fujita wrote:
>> create_index_path builds multiple index paths for a plain relation. How
>> about renaming the function to create_foreign_paths?
>
> I meant "create_foreignscan_paths". I'm sorry about that.
Perhaps you are con
(2012/03/05 21:00), Etsuro Fujita wrote:
> (2012/03/05 18:21), Shigeru Hanada wrote:
>> (2012/02/21 20:25), Etsuro Fujita wrote:
>>> Please find attached an updated version of the patch.
>>
>> This v2 patch can be applied on HEAD cleanly. Compile completed with
>> only one expected warning of scan
(2012/03/05 18:21), Shigeru Hanada wrote:
> (2012/02/21 20:25), Etsuro Fujita wrote:
>> Please find attached an updated version of the patch.
>
> This v2 patch can be applied on HEAD cleanly. Compile completed with
> only one expected warning of scan.c, and all regression tests for both
> core an
(2012/02/21 20:25), Etsuro Fujita wrote:
> Please find attached an updated version of the patch.
This v2 patch can be applied on HEAD cleanly. Compile completed with
only one expected warning of scan.c, and all regression tests for both
core and contrib modules passed.
This patch allows FDWs to
2012/3/2 Peter Eisentraut :
>> with renaming to dblink_fdw_validator?
>
> Well, it's not the validator of the dblink_fdw, so maybe something like
> basic_postgresql_fdw_validator.
-1 for same reason. It's not the validator of basic_postgresql_fdw.
Using "fdw" in the name of validator which does
On tor, 2012-03-01 at 20:56 +0900, Shigeru Hanada wrote:
> How about moving postgresql_fdw_validator into dblink,
That's probably a good move. If this were C++, we might try to subclass
this whole thing a bit, to avoid code duplication, but I don't see an
easy way to do that here.
> with renami
(2012/03/01 0:33), Tom Lane wrote:
> I don't think that creating such a dependency is acceptable.
> Even if we didn't mind the dependency, you said yourself that
> contrib/postgresql_fdw's validator will accept stuff that's not
> appropriate for dblink.
Agreed. I think that these two contrib modu
Shigeru Hanada writes:
> How about removing postgresql_fdw_validator from backend binary, and
> changing dblink to use contrib/postgresql_fdw's validator? It breaks
> some backward compatibility and requires contrib/postgresql_fdw to be
> installed before using contrib/dblink with foreign servers
2012/2/29 Shigeru Hanada :
> (2012/02/29 4:07), Peter Eisentraut wrote:
>> Let's at least be clear about the reasons here. The fact that
>> postgresql_fdw_validator exists means (a) there is a possible naming
>> conflict that has not been discussed yet, and/or (b) the name is already
>> settled an
(2012/02/29 4:07), Peter Eisentraut wrote:
> Let's at least be clear about the reasons here. The fact that
> postgresql_fdw_validator exists means (a) there is a possible naming
> conflict that has not been discussed yet, and/or (b) the name is already
> settled and we need to think of a way to ma
On Feb 28, 2012, at 8:20 AM, Robert Haas wrote:
> I liked the shorter name, myself, but I'm not going to make a big deal about
> it.
pg_ is used quite a bit. what about pg_fdw?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
On tis, 2012-02-28 at 11:20 -0500, Robert Haas wrote:
> > [ snicker ] But still, Peter has a point: pgsql is not a name for
> the
> > product, it's at best an abbreviation. We aren't calling the other
> > thing orcl_fdw or ora_fdw.
> >
> > I think either postgres_fdw or postgresql_fdw would be fi
On Tue, Feb 28, 2012 at 11:02 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 24, 2012 at 5:31 PM, Peter Eisentraut wrote:
>>> Could we name this "postgresql_fdw" instead? We already have several
>>> ${productname}_fdw out there, and I don't want to get in the business of
>>> having to
Robert Haas writes:
> On Fri, Feb 24, 2012 at 5:31 PM, Peter Eisentraut wrote:
>> Could we name this "postgresql_fdw" instead? We already have several
>> ${productname}_fdw out there, and I don't want to get in the business of
>> having to guess variant spellings.
> If you don't like variant sp
On Fri, Feb 24, 2012 at 5:31 PM, Peter Eisentraut wrote:
> Could we name this "postgresql_fdw" instead? We already have several
> ${productname}_fdw out there, and I don't want to get in the business of
> having to guess variant spellings.
If you don't like variant spellings, having anything to
(2012/02/25 7:31), Peter Eisentraut wrote:
> Could we name this "postgresql_fdw" instead? We already have several
> ${productname}_fdw out there, and I don't want to get in the business of
> having to guess variant spellings.
I worry name conflict with existing postgresql_fdw_validator, which is
Could we name this "postgresql_fdw" instead? We already have several
${productname}_fdw out there, and I don't want to get in the business of
having to guess variant spellings.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
(2012/02/15 20:50), Etsuro Fujita wrote:
> (2012/02/14 23:50), Tom Lane wrote:
>>> (2012/02/14 17:40), Etsuro Fujita wrote:
As discussed at
that thread, it would have to change the PlanForeignScan API to let the
FDW generate multiple paths and dump them all to add_path instead of
>>>
2012/02/21 0:58 "Kevin Grittner" :
>
> "Albe Laurenz" wrote:
>
> > I read the example carefully, and it seems to me that it is
> > necessary for the read-only transaction (T3)v to be SERIALIZABLE so
> > that T1 is aborted and the state that T3 saw remains valid.
>
> Correct.
Hm, agreed that isolat
"Albe Laurenz" wrote:
> I read the example carefully, and it seems to me that it is
> necessary for the read-only transaction (T3) to be SERIALIZABLE so
> that T1 is aborted and the state that T3 saw remains valid.
Correct.
> If I understand right, I agree with your correction.
:-)
-Kevi
Kevin Grittner wrote:
> > If your query involves foreign scans on two foreign tables on the
> > same foreign server, these should always see the same snapshot,
> > because that's how it works with two scans in one query on local
> > tables.
>
> That makes sense.
> > So I think it should be REPEAT
"Albe Laurenz" wrote:
> If your query involves foreign scans on two foreign tables on the
> same foreign server, these should always see the same snapshot,
> because that's how it works with two scans in one query on local
> tables.
That makes sense.
> So I think it should be REPEATABLE READ
I wrote:
> Shigeru Hanada wrote:
>>> - Since a rescan is done by rewinding the cursor, is it necessary
>>>to have any other remote isolation level than READ COMMITED?
>>>There is only one query issued per transaction.
>>
>> If multiple foreign tables on a foreign server is used in a local
q
2012年2月17日6:08 Shigeru Hanada :
> (2012/02/17 2:02), Kohei KaiGai wrote:
>> I found a strange behavior with v10. Is it available to reproduce?
>
>> I tried to raise an error on remote side.
>>
>>postgres=# select * FROM ftbl WHERE 100 / (a - 3)> 0;
>>The connection to the server was lost.
Shigeru Hanada wrote:
>> - Since a rescan is done by rewinding the cursor, is it necessary
>>to have any other remote isolation level than READ COMMITED?
>>There is only one query issued per transaction.
>
> If multiple foreign tables on a foreign server is used in a local
query,
> multipl
(2012/02/17 0:15), Albe Laurenz wrote:
> Shigeru Hanada wrote:
>> Thanks for the review. Attached patches are revised version, though
>> only fdw_helper_v5.patch is unchanged.
>
> Two questions:
> - Is it on purpose that you can specify all SSL client options
>except "sslcompression"?
No, ju
2012年2月16日13:41 Shigeru Hanada :
> Kaigai-san,
>
> Thanks for the review. Attached patches are revised version, though
> only fdw_helper_v5.patch is unchanged.
>
> (2012/02/16 0:09), Kohei KaiGai wrote:
>> [memory context of tuple store]
>> It calls tuplestore_begin_heap() under the memory context
I found a strange behavior with v10. Is it available to reproduce?
In case of "ftbl" is declared as follows:
postgres=# select * FROM ftbl;
a | b
---+-
1 | aaa
2 | bbb
3 | ccc
4 | ddd
5 | eee
(5 rows)
I tried to raise an error on remote side.
postgres=# select * FR
Shigeru Hanada wrote:
> Thanks for the review. Attached patches are revised version, though
> only fdw_helper_v5.patch is unchanged.
Two questions:
- Is it on purpose that you can specify all SSL client options
except "sslcompression"?
- Since a rescan is done by rewinding the cursor, is it nec
Harada-san,
I checked the v9 patch, however, it still has some uncertain implementation.
[memory context of tuple store]
It calls tuplestore_begin_heap() under the memory context of
festate->scan_cxt at pgsqlBeginForeignScan.
On the other hand, tuplestore_gettupleslot() is called under the
memory
(2012/02/14 23:50), Tom Lane wrote:
> Shigeru Hanada writes:
>> (2012/02/14 17:40), Etsuro Fujita wrote:
>>> As discussed at
>>> that thread, it would have to change the PlanForeignScan API to let the
>>> FDW generate multiple paths and dump them all to add_path instead of
>>> returning a FdwPlan
Shigeru Hanada writes:
> (2012/02/14 17:40), Etsuro Fujita wrote:
>> As discussed at
>> that thread, it would have to change the PlanForeignScan API to let the
>> FDW generate multiple paths and dump them all to add_path instead of
>> returning a FdwPlan struct.
> Multiple valuable Paths for a sc
(2012/02/14 19:42), Shigeru Hanada wrote:
> (2012/02/14 17:40), Etsuro Fujita wrote:
>> As discussed at
>> that thread, it would have to change the PlanForeignScan API to let the
>> FDW generate multiple paths and dump them all to add_path i
(2012/02/14 17:40), Etsuro Fujita wrote:
> OK. But my question was about the PlanForeignScan API.
Sorry for misunderstanding. :(
> As discussed at
> that thread, it would have to change the PlanForeignScan API to let the
> FDW generate mul
(2012/02/14 15:15), Shigeru Hanada wrote:
> (2012/02/13 20:50), Etsuro Fujita wrote:
>> The patches have been applied, but role-related regression tests failed
>> in my environment. I fixed it in a similar fashion of
>> /src/test/regress/sql/foreign_data.sql. Please find attached a updated
>> pat
(2012/02/13 20:50), Etsuro Fujita wrote:
> The patches have been applied, but role-related regression tests failed
> in my environment. I fixed it in a similar fashion of
> /src/test/regress/sql/foreign_data.sql. Please find attached a updated
> patch for the regression tests.
Good catch, thanks
(2012/02/10 20:39), Shigeru Hanada wrote:
> (2012/02/08 20:51), Shigeru Hanada wrote:
>> Attached revised patches. Changes from last version are below.
>
>
> I've found and fixed a bug which generates wrong remote query when any
> column of a foreign table has been dropped. Also regression test
(2012/02/02 18:24), Marko Kreen wrote:
> I think you want this instead:
>
>https://commitfest.postgresql.org/action/patch_view?id=769
With modified version of pgsql_fdw which uses row processor to retrieve
result tuples, I found significant performance gain on simple read-only
pgbench, though
Thanks for the comments!
(2012/02/06 5:08), Kohei KaiGai wrote:
> Yes. In my opinion, one significant benefit of pgsql_fdw is to execute
> qualifiers on the distributed nodes; that enables to utilize multiple
> CPU resources efficiently.
> Duplicate checks are reliable way to keep invisible tuples
2012/2/2 Marko Kreen :
I think you want this instead:
 https://commitfest.postgresql.org/action/patch_view?id=769
Somehow I've missed this cool feature. Thanks for the suggestion!
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
2012年2月1日12:15 Shigeru Hanada :
> (2012/01/30 4:39), Kohei KaiGai wrote:
>> I checked the "fdw_helper_funcs_v3.patch", "pgsql_fdw_v5.patch" and
>> "pgsql_fdw_pushdown_v1.patch". My comments are below.
>
> Thanks for the review!
>
>> [BUG]
>> Even though pgsql_fdw tries to push-down qualifiers being
On Tue, Jan 31, 2012 at 8:56 PM, Robert Haas wrote:
> 2012/1/29 Kohei KaiGai :
>> Remote SQL: DECLARE pgsql_fdw_cursor_0 SCROLL CURSOR FOR SELECT
>> a, b FROM public.t1 WHERE (a > 2)
>> (3 rows)
>
> Shouldn't we be using protocol-level cursors rather than SQL-level cursors?
I think you want
(2012/02/01 3:56), Robert Haas wrote:
> 2012/1/29 Kohei KaiGai:
>> Remote SQL: DECLARE pgsql_fdw_cursor_0 SCROLL CURSOR FOR SELECT
>> a, b FROM public.t1 WHERE (a> 2)
>> (3 rows)
>
> Shouldn't we be using protocol-level cursors rather than SQL-level cursors?
Yes, we should, if we have pro
2012/1/29 Kohei KaiGai :
> Remote SQL: DECLARE pgsql_fdw_cursor_0 SCROLL CURSOR FOR SELECT
> a, b FROM public.t1 WHERE (a > 2)
> (3 rows)
Shouldn't we be using protocol-level cursors rather than SQL-level cursors?
> [Design comment]
> When "BEGIN" should be issued on the remote-side?
> The c
Hi Harada-san,
I checked the "fdw_helper_funcs_v3.patch", "pgsql_fdw_v5.patch" and
"pgsql_fdw_pushdown_v1.patch". My comments are below.
[BUG]
Even though pgsql_fdw tries to push-down qualifiers being executable
on the remove side at the deparseSql(), it does not remove qualifiers
being pushed do
On 12/14/2011 09:02 AM, Shigeru Hanada wrote:
> Here I'd like to propose three incremental patches:
>
> 1) fdw_helper_funcs_v3.patch...: This is not specific to pgsql_fdw, but
> probably useful for every FDWs which use FDW options...
> 2) pgsql_fdw_v5.patch: This patch provides simple pgsql_fdw
>
(2011/12/13 18:57), Albe Laurenz wrote:
> Maybe I'm missing something, but if pushdown worked as follows:
>
> - Push down only system functions and operators on system types.
> - Only push down what is guaranteed to work.
Oh, I didn't care whether system data types. Indeed user defined types
wou
(2011/12/13 20:04), Heikki Linnakangas wrote:
> The SQL/MED spec handles this with the concept of "routine mappings".
> There is syntax for defining which remote "routines", meaning functions,
> correspond local functions:
>
> CREATE ROUTINE MAPPING FOR designator>
> SERVER [ ]
>
> is FDW-
On 13.12.2011 11:57, Albe Laurenz wrote:
Tom Lane wrote:
Shigeru Hanada writes:
(2011/12/12 22:59), Robert Haas wrote:
... I feel like we might need a system here that
allows for more explicit user control about what to push down vs.
not,
rather than assuming we'll be able to figure it out
Tom Lane wrote:
> Shigeru Hanada writes:
>> (2011/12/12 22:59), Robert Haas wrote:
>>> ... I feel like we might need a system here that
>>> allows for more explicit user control about what to push down vs.
not,
>>> rather than assuming we'll be able to figure it out behind the
scenes.
>> Agreed.
Shigeru Hanada writes:
> (2011/12/12 22:59), Robert Haas wrote:
>> ... I feel like we might need a system here that
>> allows for more explicit user control about what to push down vs. not,
>> rather than assuming we'll be able to figure it out behind the scenes.
> Agreed. How about to add a per
1 - 100 of 134 matches
Mail list logo
